The general idea is that:
- 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;
- if you have released a piece of software with a bug, you'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;
- 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?
We accepted that bugs are fact of life, and instead of burdening the engineers with fear, we reduce the scope of damage through data: we use canaries, experiments and monitoring to limit the damage and react fast.
Going against human nature as a result just slow things down. The other benefits to above setup is engineers are less afraid to make mistakes and are willing to try ideas more since it is now very cheap to try them
There are times when you need to be more thorough such as medical devices, space programs, and so on as they might risk human life, but for the most part you will go really far with above
Disclaimer: current google employee
Also, I've never seen a developer who behaved like S did in the story.
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.
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.
There's no middle ground :(
On the other hand, if you can ship something a few weeks faster that might have a few bugs, but the customer never notices, I can understand why a business would reward that.
> One Google engineer from back then says the most remarkable thing about the co-founders' code was that when it broke, users would see funny error message: "Whoa, horsey!"
That said, it is not normal, in my country at least, to fire people.
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.)
Small company : fired. Assume someone out there is better than you. Unethical due to desperation. Probably why company remains small unsuccessful.
Medium: Put in blacklist and harassed with reviews until you repair your credibility or leave voluntarily.
Large company: Can’t fire you as that would affect their reputation. Alienation within company until you repair credibility or leave.
The large company description is speculation on my part and could be wrong.
BTW my impression is that, within that peer group, both Google and Amazon are on the better side. They don't have "move fast and break stuff" as a core engineering value.
I have (personally) been fortunate never to have worked with an “S”, so I think the author is being overbroad.
If you write software for production and don't do unit testing then you are in the wrong job.