When Should I Blindly Accept Engineering Best Practices?

I want to touch on an open ended question and an often relevant engineering topic: when to follow best practices. I’m specifically talking about those in software engineering, however, the same ideas can apply to many different engineering fields.

This may be a controversial opinion and I do not expect everyone to completely agree with me. However, I believe most people can be categorized into one of the following two groups.

The first group are people who question best practices. Most people fall into this category, especially high-performing, entry-level engineers. This is because curiosity and logical reasoning are essential traits in this field. Analytic thinking is rewarded because it results in high quality output and furthers technical advancements. But unlike in science and math, engineering requires the systematic calculation of tradeoffs and there’s often not one right answer. Engineers like to understand these calculations and why the results are the way they are. If it’s not clear why a best practice exists, or what the rationale was that went into its acceptance, these people are likely to question it themselves, to either prove or disprove its validity.

And the other group are those who immediately take best practices as the golden truth. At a surface level, this makes sense as they’re best practices, so we should always follow them. Often people that fall into this group have a more limited formal background in computer science or engineering, independent of their experience level or role. And I’m not saying this group is wrong. Actually, most of this post argues quite the opposite.

Your Role as an Engineer

Before we dive deeper, let’s first ensure we know what a best practice is. A best practice is a method or technique that has consistently shown superior results over a long time horizon and is considered a standard or benchmark within an industry. In engineering, best practices are widely adopted and have been tested and refined to ensure optimal outcomes in general situations.

Now it’s important to reiterate what your job is as an engineer. To many’s disappointment, it’s not to fix bugs or to write the best code your company has ever seen. Your primary job is to create business value. This is what you’re paid to do. So when you spend time on tasks that do not produce immediate impact, you must discount their value. Like in finance, there’s a concept of a discounted present value, which is “the current value of a future sum of money or stream of cash flows given a specified rate of return” [1] In other words, it’s the amount you’re willing to pay now, in the present, for expected future returns. In engineering, when you rearchitect a system or refactor some code, it might prevent future bugs or increase the speed of feature delivery, but these future value streams must be discounted to their present rate. You are being paid today, for work being completed today, that may not materialize value until the distant future. Minimizing that gap between when you’re paid and when you deliver business impact makes you a more effective and valuable engineer.

And this is where the question of best practices comes into play.

Best practices provide a proven framework for building something. It minimizes the number of decisions you need to make in order to get something created. So the effort required to validate a best practice often detracts from the core goal of delivering output, which should be your primary focus.

So I do believe there’s a right answer to this question. In general cases, it is significantly better to blindly accept best practices when the new project’s goal is to deliver new or incremental value and is not an operational improvement on an existing feature.

Let’s dig into why.

Directing curiosity towards the right goals

I mentioned this before, but as an engineer, curiosity is an essential trait. But it’s crucial to direct that curiosity towards things that directly impact your goals. Investigating the validity of a best practice can be time-consuming and not feasible for one individual. So when you’re writing a design document, it’s completely fair to blindly accept a best practice and move on to more important and nuanced details to more efficiently use your time and energy.

For instance, let’s say you are working on a new project in ReactJS. You need to decide between class components and functional components. You look at the documentation and notice that ReactJS recommends using functional components instead of class components. The documentation states they are easier to read, maintain, and offer better performance. Great! You don’t need to dig into why functional components are more performant and easier to maintain. It’s okay to accept this statement as fact, so the decision has already been made for you.

Trusting the aggregated wisdom of the community

Best practices are generally accepted by the engineering community as the optimal way of doing something. These practices have undergone numerous rounds of adoption, investigation, and debate. Their continued use is a testament to their efficacy. So, while they may have drawbacks, trusting the collective wisdom of the engineering community is more productive than examining it. So believe me, you’re not the first person who wants to question why a best practice exists. But the reality is, the collective argument for a best practice’s use is inherently stronger than any individual’s questioning of it.

Avoiding contrarianism for its own sake

Some engineers might disagree with best practices simply to appear smarter than their peers or just for the sake of disagreement. If you’re one of these people, I challenge you to take a step back and make sure you fully understand your argument’s points in depth before attempting to challenge it. Oftentimes the loudest voice isn’t the most correct.

It’s YOUR responsibility to understand best practices

This point relates to the previous one but it’s essential to remember that understanding a best practice lies with the curious engineer who questions it. It’s not the responsibility of the person employing the practice to explain to you why it exists. Because most of the time, he doesn’t know (or need to know) why.

If you’re a reviewer of a design document and you come across an implementation that is justified by a “best practice”, don’t just immediately question it unless you understand its pros and cons. By using a best practice, the writer was able to focus on the differentiated aspects of their work, knowing that the framework they’re using has been tested and proven effective.

Take the example of code reviews, a best practice in software development. By using this mechanism in your team or company, you can trust that your code is being checked for quality, readability, and maintainability, allowing you to focus more time on creating features and functionality that add value to your project while minimizing unexpected bugs.

Recognizing personal limitations

Also, before questioning something, consider your own background and expertise. A degree in computer science or relevant experience in a specific domain might provide critical insight, but weigh this against the accumulated wisdom of the community that supports the best practice.

For instance, if you have limited experience with database design, it’s wise to rely on established best practices rather than attempting to reinvent the wheel. The community has collectively determined that these practices lead to efficient and maintainable databases, so trust their expertise. They just know more than you.

Conclusion

So, there’s my opinion. I believe that blindly following best practices is almost a best practice in itself. Like anything in engineering, it has its pros and cons, but in most cases, it should be acceptable to just go along with it at face value. While curiosity and skepticism are valuable traits for engineers, it’s essential to direct these qualities towards the right goals. Accepting best practices without questioning them allows you to focus on creating value by trusting the collective wisdom of the engineering community. In most cases, the benefits of adhering to best practices far outweigh the potential gains from challenging their validity.

But also remember, as you gain a better understanding of your project’s specific requirements, you can tweak and adapt your decisions to suit your needs. Remember, best practices are general guidelines and not strict rules. They provide a strong foundation, but it’s essential to be flexible and open to adjustments that can increase your project’s value, and, in turn, your own.

References

Brealey, Richard A., Stewart C. Myers, and Franklin Allen. 2006. Principles of Corporate Finance, 8th ed. New York: McGraw-Hill/Irwin