The Illusion of ‘Best Practices’

There are no ‘best practices’ in code.

You [cleanly] write what works, relying on the moment to guide you.

Such is the way, and the way out of over-engineering.

‘Future-proofing’ is largely driven by anxiety.

The most effective changes in your code come when you have no choice but to change things. And at that time, it will not feel like a chore. Things just happen under your fingertips.

If you’re paying attention, you’ll notice just how frequently the touted ‘best practices’ change with the tides.

What’s genius today, is dismissed as legacy tomorrow.

And there’s nothing wrong with that.

It may very well be, that yesterday’s code is laughable. I feel this almost daily, sifting through my files.

Why is a given piece of software lauded or admonished …

Is what they’re saying reasonable?

You want the freedom to take their standards, or leave them.

Or take them, and modify them to your liking. You’re driving.

Blindly follow such ‘best practices’, and you’ll find yourself constantly tailgating what they do next.

You’ll build, but what you build will not be your own.

Hit a bug, and you’re looking for ‘their fix’.

Hit a deprecation, and you’re looking for ‘their ‘advice’.

Real engineers don’t spend their days learning new frameworks for the sake of adding more artillery to their arsenal.

They’re busy building what they want to build, destroying what they want to destroy, and forging their own standards along the way.

Twitter: @PrefectureCo