My recollection is that Dan was working at Microsoft during "Third real job (2015-2017)." (He has a couple of posts in this timeframe where he refers vaguely to his employer. "Hiring Lemons" is one.)
I would be interested to know what teams Dan worked on while he was at Microsoft. He says that team #1 couldn't build their source code on most days, and that while team #2 was better, they still often had broken builds in origin/master.
I love the section he wrote on Microsoft. He is clearly a master of the backhanded compliment:
> However, I can already tell that this experience broadened my horizons. Two examples I got out of the experience are a better understanding of how sales worked and I have a better idea of the range of processes that exist across different teams.
> To the first point, the company produced some decent products backed by a world class sales team. Watching the sales team work was a revelation. The sales people would regularly go in and create sales even when the product wasn’t the best thing for customers. I’d always known that sales was at least as important as engineering, but seeing this in action was different from knowing in the abstract.
> To the second point, I once wrote a blog post on build uptime where I looked at uptime data that seemed surprisingly bad to me and said
> at every place I’ve worked, two 9s of reliability (99% uptime) on the build would be considered bad. That would mean that the build is failing for over three and a half days a year, or seven hours per month. Even three 9s (99.9% uptime) is about forty-five minutes of downtime a month. That’s kinda ok if there isn’t a hard system in place to prevent people from checking in bad code, but it’s quite bad for a place that’s serious about having working builds.
> A number of people responded with comments like “lololol that guy has been pretty lucky in the team’s he’s worked on”. I didn’t think much of those comments until this job. At my first team on this company, we couldn’t build on most days for most of the time I was there! My second team was better, but I would regularly get broken builds when I fetched and merged from origin/master. I had no idea that companies that considered themselves serious about development could have practices like this and it’s good to have this new information.
I would be interested to know what teams Dan worked on while he was at Microsoft. He says that team #1 couldn't build their source code on most days, and that while team #2 was better, they still often had broken builds in origin/master.