I remember reading a blog post years ago, now lost out there on the internet, about the concept of focusing your attention on actions which have asymetric beneficial effects. For example, doing a short amount of physical exercise pays back with enormous longevity and health benefits.
That post came to mind because I’ve recently noticed an opposite kind of imbalance, one where a small action creates a big annoying hindrance. It has to do with what the industry calls “best practices”, and I often see it in system/code reviews:
In my view, the entire concept of the “best practice” should be considered anathema to engineers. Best practices distilled to their simplest form are, ultimately, a form of engineering via checklist. By this I mean any situation where we have essentially surrendered some amount of decision making and critical thinking to other people who have formed a “best practice list”.
This is opposed to reasoning for ourselves at every possible decision making point for why we make any particular choice.
Sure, checklists are useful for getting an implementation to a form that is “decent and not the absolute worst possible”. But in my experience they are a middle-of-the-road solution, rarely ever the actual “best” solution for your particular situation. Because of this, I say it’s an ultimately harmful way to go about doing engineering. When you work with increasingly complex systems, or need to work within bespoke contexts unique to a business’s situation where other needs are critically at play (e.g. time, complexity, availability, budget, etc.), you will encounter an increasing number of situations where the best practice simply is not the best.
Maybe the problem stems from the term itself. The name alone implies they are the ‘best’ way to do anything. There would be a lot less of a problem if we all agreed to call them “recommended practices that generally work most but not all of the time”. But by calling them ‘best’, we now have engineers everywhere taking this at face value and following them with strict observation, not straying from them at all, unable to answer why they are preferred. I argue this: abandon the concept of ‘best practices’ as absolute solutions and instead recognize them only as potential ones.
Rigidity to best practices also just incentivizes poor engineering decisions. There are a number of times I have encountered implementation problems where I could either 1. try to implement a solution I discovered that would confer a non-obvious benefit, but doing so, I predict, would lead to someone calling me out for not following a so-called best practice, or 2. I simply abandon the idea and go with the so-called best practice in order to get my work approved. I find that if you do stand your ground, and argue your case, others will also come to realize the benefits of your solution over the ‘best’ practice. But this cannot always be, because sometimes time constraints often make this litigation impossible.
Unless there is clear evidence a non-best-practice is suboptimal or harmful for a situation, it’s completely fine to have some implicit trust in the author’s decision to select an implementation that is not a best practice. Your colleague, a fellow engineer, has used their brain to go with one method over another. It’s your job now to determine if there’s a difference in the ultimate effect it has, not blindly see if it checks best practice boxes.
If there is no difference, why make them justify their decision? Why waste time forcing others to redo their work for no difference in result? To be ignorant of the possible reasons why an author decided to opt for one method over another is to reduce them to someone unable to reason or do anything on their own. I’m not saying to be lazy, cut corners, or accept any solution which does. In fact, just the opposite.
A review should be two-sided. Instead of saying “not best practice”, the reviewer should always provide justification for why their recommendation is objectively better. They need to explain why it is worth the time to implement in the context of the business needs, and critically, demonstrate what the actual effective difference would be. In doing so, the reviewer will either: 1. teach the author why the recommendation would be superior, or 2. discover, by trying to justify their recommendation, that there actually is no difference at all. By having the reviewer justify the best practice, this also achieves better balance in the review process and may incentivize, as I explained earlier, better engineering practices overall. It does not leave the author, pressured to finish on a deadline, in a disadvantaged position to either defend or resign their idea altogether in order to get the merge done.
A computer science quote comes to mind: “premature optimization is the root of all evil”. The very practices people cultishly abide by may themselves be suboptimal or the cause of unnecessary maintenance! I have found this is especially true any time something broadly recommends abstraction. Think of it this way: let’s say method X that is technically more extensible than method Y. Now ask yourself: Does the context have or will ever be expected to have enough complexity, that implementing X would lead to a net-reduction in complexity? Or is the project actually small enough that X may actually introduce more complexity? Would implementing method X force the author to undo a lot of work and introduce major business delays? Will these delays ever lead to a return on value?
This is why I am typically happy to approve work as long as it demonstrates: 1. it affects a change that works, 2. it isn’t suboptimal or harmful, and 3. it doesn’t add unnecessary future maintenance. If it meets all of these criteria, honestly, who cares if it doesn’t follow the best practice? To reject someone’s work for some other arbitrary practice that confers no other benefit is to give net-negative value in a personal quest to be some kind of inquisitor, making them answer for their implementation which slightly deviated from some list.
As an engineer, abandon best practices and all forms of contextless broad recommendations as anathema. Instead, harness your capacity to understand effects, and give your full attention to each engineering issue you encounter on a case-by-case basis to make your own determinations.