Asymmetric payoffs
Heads, you break even. Tails, you lose. Would you take that deal? Heads you break even, and tails you lose?
That’s a terrible deal. We should avoid that at all costs. So let me talk a little bit about that in terms of software engineering.
In software engineering, people want reliability and consistency. With any other kind of engineering, it’s the same way. We want our cars to just work. We want our computers to just work. People do not want to hire software engineers who break production. I think that’s about as universal as you can get.
People will vividly remember fixing production, reverting pull requests, and stuff like that, and they will not be happy.
So what we need to do is focus on reliability and consistency.
There is not going to be much benefit to rushing, because people mostly won’t notice. And there is going to be a pretty big downside to rushing. Rushing is bad. Rushing increases the odds of mistakes.
Caution and measure will win you treasure.
Say, one day, you rush something out a couple hours faster than expected. Does anyone notice? If your company is like most companies, no one notices.
Essentially you are rushing for no benefit while increasing that odds that you make mistakes.
People will not remember if you do something one hour faster than expected, but people will remember the dumpster fire you caused by pushing broken code into production. And people will see that it takes you twice as long as everyone else to get your code through quality assurance.
It is much easier to avoid mistakes than to cover yourself in glory by rushing.
Companies lose money, companies lose customers, and companies look bad when things break. So we really need to put more emphasis on avoiding mistakes. And that will benefit our careers as well.