Diving a bit deeper into a previous article, the first practical advice I pass on is to learn why something is a "best practice" and then use it.

A senior developer I worked with in the past explained it to me using this Michael Jordan quote: "You can practice shooting eight hours a day, but if your technique is wrong, then all you become is very good at shooting the wrong way. Get the fundamentals down, and the level of everything you do will rise."

"But Al - I see developers doing horrible things in the name of "best practice" all the time, how is that okay ..."

Sometimes we forget that a "best practice" has two types as its definition "method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means" OR "it has become a standard way of doing things."

A lot of the time, what started as the first part slowly became the second part, and this is only natural as teams develop over time.

A best practice is only "best" if it continues to deliver on that high value, and it should be re-evaluated and assessed every so often to see if the practice still is "best."

This is why I say it's essential to learn WHY something is a best practice - what pain did this solve? New people don't know that pain, so I always let a new person experience it, too, so then they also understand the importance of that best practice.