There's no such thing as a best practice

Imagine the scene:

– We should do it this way!
– Why Bob, that sounds stupid?
– Not at all, that's a best practice Maggie!

The best maths teacher I ever had was a stubborn man. When studying a new theorem, he used to insist that we learn the hypotheses and not only the conclusion. Pythagoras never said that "hey, take a triangle, a**2 + b**2 = c**2". He said that "IF the triangle is right, THEN a**2 + b**2 = c**2". Crazy hey?

It may sound like a joke, but in the tech industry, many people maintain in their head a long list of "best practices". And they're so focused on remembering the conclusion that they forget that there must be some kind of hypotheses or context for their cherished conclusion to hold true. It becomes a soup of universal truths and religious beliefs that "true" engineers must follow on every project.

Those practices are not necessarily bad. Sometimes they're even relevant. But in my experience, we'd be better off without that expression and with our brains turned on. If you don't know why you're doing something, just think and decide if it's relevant to your context, project, team, budget, deadline, etc. If you know, you can explain it to others, and the reasons will drive better alignment and broader initiatives to reach common goals in the team.

Now that may increase the noise. You can't spend 3 hours deriving every other decision from first principles and values every time you want to add a button to your Twitter for Pets. That's where standards come in.

A standard is a document that formally describes a process or a way of doing things, and the context to which it applies or not. A standard is a lot less hand-wavy than a "best practice". It's generally defined at team or company level. It doesn't stop the conversation, it helps the team move forward instead. And if you have good reasons to opt-out, you can.

A colleague told me recently that I should use our processes because/when they work, but always stay result oriented. That's great advice. Use standards, not "best" practices.