It was around a decade ago when I met a guy—let’s call him Alex—on an internet forum of fellow movie buffs. The initial interaction was just me fishing for movie recommendations, but I got more and more curious about the extent of his knowledge about movies.

Accidents, tragedies, or negative outcomes, all entice a usual reaction: who’s at fault for this? Who is to blame? Our instinct drives us in that direction. The reasoning seems pretty obvious: if something bad has happened, it must have been because of someone screwed up by being negligent or maybe they were malevolent all along.

This article began with a simple question - when will we run out of oil to drill? It’s likely that you must have come across the answer that puts the date around 2050, which is derived by dividing the proven reserves we have by the annual consumption. Another answer considers the game of demand and supply. Oil will progressively get expensive as we run out of it, in the face of which, the alternatives will become much cheaper. That is true, but it still carries an unspoken assumption that we are, in fact, running out of oil pretty quickly.

Recently, I learned an interesting thing about my programming ability. That I have become faster at it over the years. In software literature, being ‘fast’ almost carries a negative connotation — of being reckless and clumsy vs. taking a more nuanced approach: using a pen and paper, and deliberating over the solution. Fred brooks famously said only 16% of the estimate should be devoted to actual coding, while 33% to planning and 50% to testing and debugging.

An important thing I learned early in my career was that best practices need not to be accepted at face value. There are so many nuances to Software development that a rule followed religiously can bite you in the back somewhere in the future. It’s not easy to realize this, though. Often, you read about an idea, you are sold to it (without considering its wider implications) and next thing you know you’re married to it.