Over the course of my career, I’ve found individuals that walk around spewing a fixed set of idioms. Not understanding them, this feels posey. However, turns out they can be pretty powerful once you understand them. Here are some of my favourite tech idioms.
Occam’s Razor (Law of Parsimony)
“With competing hypotheses about the same prediction, one should select the solution with the fewest assumptions.”
I love this saying as it accelerates decision making between multiple valid choices. I’m a sucker for saving time and cognitive energy. Best of all, I find the simplest answer will often be the most correct as well. Ineviably, some subtleties may be glossed over or missed by a simple answer. However, a simple solution is often more universal and generalizable in all sorts of situations.
“You ain’t gonna need it”
Prefer iteration over heavy upfront planning. This is important as we often forget that innovation requires rapid experimentation. While one can think for long periods, eventually you’ll need to deliver and test your ideas. I strive to hit the right balance between planning enough, and execution. At larger scale, organizations hire a mix of people that will focus on both disruptive and sustaining innovation.
“There’s more than one way to skin a cat”
Disclaimer: I do not condone animal cruelty!
This is often a reminder that there’s multiple journeys in order to fulfill a goal. Don’t overthink. Weigh your options. Commit to the simplest one that will support evolving requirements. Bias towards action.
Goodhart’s Law
“When a measure becomes a target, it ceases to be a good measure”
If this isn’t self-explanatory, imagine any scenario where people are rewarded for a certain task that can be measured. Most often, people will find ways to gamify the situation, and find loop-holes in the way you’re measuring them. Take for example, lines of code or story points, both terrible measures of developer productivity. In the former, developers can easily pad their code or even worse implement useless/redundant functionality. In the latter, teams can easily inflate their numbers and drastically overestimate in order to look good (aka “sandbagging”). I’m not trying to say all metrics are bad, however they need to be re-examined from time to time and carefully considered what purpose they are serving. Does this metric drive you closer to your outcome? Or are you just producing more output?
Sisyphean Effort
In Greek mythology, Sisyphus was a man who was trying to be clever. His punishment was to push a boulder up a steep hill. As the boulder reaches the top, it inevitably rolls down again, repeatedly, for all eternity. Some developers feel this way about their work, which is a pity and a shame. If you ever find yourself this way, why are you willing to stay in such a shitty situation? Work on something that brings you joy, with people that energize you!