I originally posted this post on my blog.
We, as coders, take pride in preaching and following best practices.
Don't write SQL, use an ORM.
Don't throw exceptions, use Results.
Don't write conditionals, use design patterns.
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.
Recently, 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.
Starting out or already on the software engineering journey? Join my free 7-day email course to refactor your coding career and save years and thousands of dollars' worth of career mistakes.
Very true! Before a complete rewrite, let's do what we can really do.