Do big companies like Google and Amazon fire developers for buggy releases?

Not going to answer for Google, but my company, which I assume has a philosophy pretty similar to Google, will typically not fire developers for buggy releases, but not for the crappy reasons mentioned in the OP.<p>The general idea is that:<p>- everybody writes buggy code, once in a while – living under the pressure of being fired for an error that anybody could have made is not conductive to innovation and experiments;<p>- if you have released a piece of software with a bug, you&#x27;re now expected to fix it or help fix it and make sure that it never happens again to you or anyone else – not run away and update your resume;<p>- both learning about the bug and fixing it are learning experiences – at this stage, the company has already (involuntarily) paid for you to get this experience, so fire the person who is now the most knowledgeable about a problem?

In 30 years of software development, I&#x27;ve never seen a dev fired because of a buggy release. You get fired for 3 reasons: long, ongoing performance problems; violating company practices like stealing or sexual harassment; or when the company needs to cut salary and staff to meet numbers.<p>Also, I&#x27;ve never seen a developer who behaved like S did in the story.

I&#x27;m always wary of stories such as this one. Everytime I encountered people complaining they were doing everything by the book while that <i>one</i> guy&#x2F;gal over there gets all the credit doing mediocre work, there were more variables involved. Maybe H is a close friend and S has a bitchy resting face the author can&#x27;t get past, or maybe H takes so long polishing his&#x2F;her code and understanding business requirements that management never trust him&#x2F;her with bigger tasks, while S gets the proverbial thing done fast and good enough for the business meeting next week. Don&#x27;t get me wrong, I love me some beautiful and tested code that works well, but it takes time, and sometimes time is imperative when you care about money, and in a business setting, that&#x27;s always.

I have never seen any case of a developer holding the project to ransom in order to fix a bug, as alluded to in the article.<p>That said the key point that those who are always firefighting and ‘saving the day’ do often get the recognition as opposed to the people who squat the bugs early, follow sane processes and test their own stuff well is true.<p>But the question is about tech companies (not outsourcing shops like in the top response I saw). And I think the answer is a simple no.

I seriously doubt any successful software company is firing engineers for introducing bugs. They&#x27;d have no employees.<p>&gt; One Google engineer from back then says the most remarkable thing about the co-founders&#x27; code was that when it broke, users would see funny error message: &quot;Whoa, horsey!&quot;

I&#x27;ve worked at Google and Amazon and they would never fire a developer for a buggy release. All engineers write buggy code. With mentorship, code reviews, and reliable test infrastructure, they write fewer bugs. With strong QA and monitoring they ship a lot fewer bugs.<p>Google and Amazon are not dumb enough to fire an engineer who would cost 10s to 100s of thousands of dollars to replace because that engineer happened to get unlucky and push a release that slipped through all those cracks. (Doing so maliciously would be another story, and would warrant firing.)

Basically the vibe I get after a few years on HN<p>Small company : fired. Assume someone out there is better than you. Unethical due to desperation. Probably why company remains small unsuccessful.<p>Medium: Put in blacklist and harassed with reviews until you repair your credibility or leave voluntarily.<p>Large company: Can’t fire you as that would affect their reputation. Alienation within company until you repair credibility or leave.<p>The large company description is speculation on my part and could be wrong.

What is with the irrelevant stock photography throughout the post?

At traditional product-oriented companies, buggy releases are recognized as a programmer-performance issue and dealt with eventually (though as others have pointed out immediate firing would be absurd). At modern internet-facing companies, developers who produce buggy releases are rewarded. It&#x27;s not intentional. It&#x27;s what happens when performance is evaluated 100% on <i>releases</i> regardless of bugginess. If you push lots of code, you get rewarded. If you slow down to ensure quality, or spend time fixing code that already exists, you get penalized.<p>BTW my impression is that, within that peer group, both Google and Amazon are on the better side. They don&#x27;t have &quot;move fast and break stuff&quot; as a core engineering value.

The company I work at does not fire people for introducing bugs (everyone introduces bugs at some point and time). We try to find out what failures in our process (dev, test, release) contributed to the failure and try fix them. Some of the causes may be large, so it takes us time to get the organizational commitment and focus to work on them, but we do act.<p>I have (personally) been fortunate never to have worked with an “S”, so I think the author is being overbroad.

Everybody writes buggy code and those who say they don&#x27;t are kidding themselves. The most important thing is how you react to bugs being found. The right answer is to acknowledge the problem and fix it. Write a unit test so it never occurs again in this code. If you get hit by a common type of bug that&#x27;s preventable in code, often, then your unit testing is not up to scratch.<p>If you write software for production and don&#x27;t do unit testing then you are in the wrong job.

Haven’t seen anyone fired in a year at my current large company. Have seen our process deployed many times to make sure work is coordinated to make that error impossible next time.