Dan Donahue bio photo

Dan Donahue

Musician. Traveler. Programmer.

LinkedIn Github Stackoverflow

I've always found the idea of the "best practice" concerning. I think it has to do with my proclivity for being the devil's advocate. Almost any time I hear the term used, I immediately attempt to find a situation in which said "best practice" could be pointless, or even harmful.

While I was at Udi Dahan's weeklong Advanced Distributed Systems Design course a few years ago, he said: "There are no best practices - only very good practices given a certain context". He succinctly explained that which I have always felt but have been unable to put into words. I came home shortly after and found this blog post which drove the point home. Even though I'm not sure I can do a better job explaining how I feel than that post does, I'm going to try anyway.

What's Wrong With The Term

First - let's talk about the way in which it is commonly used and why that is problematic. Typically, the term "best practice" is brandished in order to win a discussion or end a debate. It's an appeal to authority. It's an attempt to shut down another point of view.

This actually does a disservice to both parties in the discussion. The party at the receiving end is talked down with a logical fallacy. But more importantly, the person who is delivering has missed a learning opportunity. They've decided that there's no more to learn, or no more thought to give a certain topic. They've figured out all they need to know about a given practice.

Second - the idea that a best practice exists presupposes that it is the best thing you can do in any situation. In reality, what it often means is that the practice has worked in the person's previous experience. If I've spent most of my career building monolithic web applications, I may have an experience bias for the practices that have helped me succeed in those situations. However, those same "best practices" may break down considerably if I'm building an OS kernel, doing systems level programming or even just building a web API. The truth is that someone can come up with a valid situation whereby the supposed best practice breaks down. And that situation need not always be vastly different from one where the practice works well.

What worries me the most is the effect of using the term "best practice". It can lead to a cruise control mindset. If you're under the impression that some practice is best always, you may not spend the time to think about whether or not it's actually helping you in your current situation. As an industry, programmers seem to be always looking for that silver bullet that frees us up from having to think about how to solve the problem currently in front of them. The thing is... solving that problem is exactly the skill that a developer brings to the table. Knowing a programming language isn't that valuable. Anyone can learn the syntax. What you're being paid to do is to analyze a problem and figure out the best way to solve it. When you stop thinking critically about the problem you're facing, instead defaulting to your supposed "best practice", you've missed a valuable opportunity to practice the skills of critical thinking and problem solving.

What To Say Instead

If you've made it this far, hopefully I've convinced you that claiming a practice is the best is problematic. There are ways to present your opinions or experiences in a way that aren't as detrimental.

You can make it a point to mention the context in which the practice excels. Qualify when to use the "best practice". Something like: "This practice works well for this context/class of problems/etc.".

Further, you can present your experience with the practice - "This practice has worked well for me in the past in these types of situations". When you've actually done something, it's more likely that you'll be able to defend your position. You'll be more likely to see if the current situation is different enough that your proposed practice may not suit it. You'll have learned deeply about the practice - both the good and the bad consequences.

There is a great saying about the usage of design patterns that I can't find so I'm going to try to remember it as best I can. "First - a developer doesn't know any design patterns. Then, they learn about design patterns and use them everywhere. Finally, they use design patterns without knowing they're doing it." The idea is that with enough experience, the developer knows how to solve a given problem based on their experiences. Their solution may look like the pattern but it wasn't intentional - they were just using their experience to solve a familiar problem.

So let's stop using the term "best practice". More importantly, never miss the valuable experience gained in analyzing and solving a problem. That's your strongest asset as a developer!