Best practice
Breaking free from interpretation, time, environment, and exaggeration
Earlier in my career, I was an advocate of best practice. But as my understanding of the technology, product, operations and people grew, I realized that most best practices don’t live up to their promises.
All of them? What gives?
This short post elaborates why best practices should be taken with a grain of salt and what to do instead of following them.
🤖🚫 Note: No AI was used to generate this content (except one image from another article). This essay is only intended for human consumption and is NOT allowed to be used for machine training including but not limited to LLMs.
Exaggerated Perception
Best practices are often someone’s interpretation of why something worked at a certain time and environment. This interpretation is often exaggerated to make a point.
The art of creating best practices
There are certain ingredients to create the perfect recipe for adoption:
Generalization
Acronym
Name-dropping
Advertisement
Generalization
The key to creating successful best practices is to make them generic enough to apply to the common pain, but not specific enough to collapse under pragmatic scrutiny.
There’s a fine balance to be made between making bold claims and being caught red-handed. The more generalized the solution, the wider its application.
While you’re at it, exaggerate a bit. SOLID can solve all code smells. REST is the best.
Acronyms
It helps to have catchy acronyms like DRY, WET, KISS, TDD, JWT, SRE, …
Acronyms create insider-jargon. They create a curiosity for those who don’t know them and pride for those who do.
Name-dropping
If you can attach the best practice to a famous brand, it’s even better: Spotify model.
Name-dropping is an effective way to borrow the credibility of something people know and trust and attach it to something new and unproven.
Advertisement
What’s the point of having generic catchy acronyms that are attached to brands, but no one knows about it?
Write about it. Do podcasts. Go to conferences. If possible, publish open-source repositories. Let the world know about it.
A good example is Kubernetes. Google needed to let the world know that it can do cloud. It created Kubernetes using their own programming language (Go) and published great resources about how they do reliability engineering.
The problem is that most companies aren’t Google in terms of infrastructure, resources, recruitment bar, and even the problem area.
That didn’t stop cargo culters from across the world to jump on Kubernetes only to create memes like this years later:
Know when to break the rules
Junior follows the rules
Senior makes up the rules
Expert knows when to break the rules
Best practices often pack some wisdom, but they’re overrated. Thinking is hard, people are lazy. We much prefer to take an off-the-shelf idea instead of thinking.
But going that extra mile makes all the difference between following blindly vs deliberately.
Best practices are not laws of nature like the speed of light. They are bendable, breakable, and sometimes contradict each other (e.g. DRY vs WET).
Critical thinking
No one knows your technology, product, operation, and people as well as you do. And if you don’t, that’s on you! The process of discovering your uniqueness holds the key to finding solutions that are fit.
Put your critical thinking hat and ask yourself:
Where does that best practice come from?
What are the nuances for that best practice to work?
Why is that particular best practice well known?
What’s the wisdom in that?
And more importantly where doesn’t it apply?
If you follow best practices to the dot, at best you end up where another company was in the past. At worse, you’ll ruin your unique edge based on someone’s exaggerated interpretation of how things worked at a certain time and environment.
Share or discuss on HackerNews.
My monetization strategy is to give away most content for free. However, these posts take anywhere from a few hours to a few days to draft, edit, research, illustrate, and publish. I pull these hours from my private time, vacation days and weekends.
You can support me by sparing a few bucks for a paid subscription. As a token of appreciation, you get access to the Pro-Tips sections as well as my online book Reliability Engineering Mindset. Right now, you can get 20% off via this link. You can also invite your friends to gain free access.