We Shouldn't Call Them Best Practices—And Blindly Follow Them

25 Dec 2024 #misc

We, as coders, take pride in preaching and following best practices.

Don’t write SQL, use an ORM. Don’t write conditionals, use design patterns. Don’t throw exceptions, use Results…Don’t do that, do this.

Those “don’t do that, do this” hide all the context in which they make sense. That’s the part we skip and don’t tell when we preach best practices.

Today, I had a call with a consulting company that needed help. They were migrating a small shop’s application from the early 2000s to a newer stack. It wasn’t written and maintained by professional software engineers. Zero best practices. Lots of copy-pasting.

Migrating that application and bringing its owners up to speed are two different challenges. They have to maintain the application once the migration is done. Using the latest and greatest best practices wasn’t an option.

Often, instead of going all in on best practices, the best path to follow is “let’s do the simplest thing that can work, without doing any more harm.”

We shouldn’t call them “best practices,” but rather “pieces of advice that worked for me under certain circumstances and might work for you too.” And we shouldn’t blindly follow them. Not all code is created equal and worth the same.