For the last week, an article from the New York Times about the working conditions at Amazon has been making the rounds on social media. It’s worth reading the whole thing, but the gist is: Amazon works you to the bone and you can’t take time off even if you’re sick, just had a baby, or your husband died yesterday. 80 hours a week is the low end of expectations.
I have no way of knowing if the article is true. The truth probably lies somewhere in between the article’s insistence that Jeff Bezos is a slave driver and Jeff Bezos’s claim that he values his employees immensely and that they’re a caring company. I suspect that some employees were treated terribly by some managers. But “some” can add up to a lot at a big company like Amazon. Even if just 1% of Amazon employees were treated as badly as the article claims, that’s about 1500 people. And that’s just if you’re talking current employees. The numbers that have left would add to that.
Whatever the truth is, my first thought was, crap, more publicity about how much it sucks to work in tech. I thought that before I even read the article. This Slate article I thought was a good response to the kerfuffle; however, it doesn’t completely dispel the idea that working as a programming is grueling. The author outlines three things that he finds off about the article:
First and foremost, good software engineers are still in high demand. For all the coders out there, writing production-level, high-quality code is still at a premium, given the amount of it that is required at this point. Combine that with the need for engineers to be able to work well with others, not be hopelessly dogmatic, and not get burnt out, and there’s generally a pretty strong argument for not treating your coders like total garbage.
Second, engineer attrition is bad. A new engineer will take months to get up to speed on an existing codebase to perform as well as her predecessor, and that’s assuming she’s as good as her predecessor (which is nearly impossible to predict for a cold hire).
Third, coding speed is highly variable. I saw work that normally would have been assigned to a team of five people given to a single high-speed engineer without incident. Some engineers simply prefer to do a more thorough job without cutting any corners, with the final 5 percent of perfection doubling the working time. Some engineers simply do additional, elective work to make their lives or the lives of their teams and other teams easier. Some engineers simply make more mistakes in the normal course of things and have to spend more time debugging to produce code of sufficiently good quality.
The first two of these, I was glad to see. Basically that good programmers, who can not only code but work well with others are still in demand and that it sucks for the company to lose one of these good programmers. The last I guess is about hours worked. If you have two days to finish something and you’re a slow coder, you might have to work round the clock to get it done. If you’re fast, you might just work a normal 8-hour day for two days in a row and be done. I’ve certainly seen that in my experience as well.
Finally, the author makes the point that we shouldn’t be too worried about the software engineers who are forced out of Amazon. They have in demand skills that can garner them a good salary. The blue-collar workers that work in the warehouses are much worse off, both from a treatment standpoint, and from an ability to find good work if they leave. We should be more worried about those conditions.