Against Best Practices

Follow best practices unless you can give a reason not to. "Best practice" is a shorthand for a lot of accumulated knowledge that you don't want to go over again every time. Also following BP makes the code more consistent and thus easier to understand. But when an argument arises, go back to the underpinnings of the best practice and work from there.

Basically if you know exactly why the best practice/rule is in place, and know for sure it does not apply, just skip it. But not before.

https://en.wiktionary.org/wiki/Chesterton%27s_fence

Often what is one developers "best practice" is another's "anti-pattern" because a lot of this is just arbitrary.

Hot take, the biggest advantage to following «best practices» is that when someone else stumbles over your project, they can follow along more easily

If it is arbitrary, it’s “standard practice”.

Yeah exactly.

A lot of the time best practice can also mean “we did it this way last time and it was ok”. I don’t think anyone is saying don’t find improvements in “what is currently defined as best practice” and if they are then that’s your problem.

There are many like that. Every practice is a trade off.

However, there are many where the cost/benefit ratio is so large that you can default to "you should just do this".

I dont think Id ever look at a company that e.g. had no CI or versioning for a large project for instance and think "they might have had a good reason for this". They didnt.

There’s usually nothing “best” about it.

That's very reasonable.

‘The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.’

The iThe

I would reverse this: if you can explain to me exactly why your so called "best practice" applies here and now, good. Otherwise it's a nice input to have in the discussion, but nothing more.

What if the "best practice" was invented by a VC funded company (like, just for example, Vercel) desperate to maintain their growth trajectory by any means necessary, including huge marketing pushes to convince everybody the "best practice" is the "best way to do things"?

It's downright dangerous to assume a "best practice" in software development somehow automatically means it's some super distilled wisdom juice. A whole lot of it, in my experience, is just hype and rapid, unquestioning cargo culting slamming in right behind the hype.

Use your fucking brain. If the "best practice" is objectively a good solution to your problem then use it. If not, think of something better.

> Therefore all progress depends on the unreasonable man.

The unfortunate corollary to this is that all retrogression also depends on the unreasonable man. The reasonable person (as defined here) maintains the status quo, for good or ill.

> Follow best practices unless you can give a reason not to.

Cargo culting much?

I'd say, follow best practices only if you can say exactly why it is best practice.

Which still has immense value.

It's standard practice to install outlets with NEMA connectors in North American buildings. Sure, you could technically swap those out with a more optimal connector that is "better" (one that prevents electricity from flowing while the plug is partially exposed, for example), but using the standard practice is best practice for human-shaped reasons that are often not apparent to early-career engineers.

It depends on your risk appetite. A best practice likely keeps you away from pitfalls known to the community of the practice but not to you. It also may keep you away from crafting a solution that is optimal for your specific circumstances not known or applicable more widely.

In high-reward / low-risk environment, such as building an indie turn-based retro-style game, go with your gut feeling unless you have a good reason not to.

In a high-risk / dubious-reward environment, such as implementing cryptography, follow the best practices to a t, unless you know intimately how things work and maybe codified some of the practices.

There is a wide gamut between these two extremes.

I don't think so. For example, If I'm writing something in a programming language I don't know by heart, I start by following the best practices recommended by the language authors, then start to flex them when they become less useful, until I hit a nice pitfall which these best practices are designed to avoid.

This allows me to start faster, and be in a better shape in short term. Then I can flex advice more and more as I understand how a language works under the hood.

I mean, consuming anything without vetting the source of the information is a bad practice in general.

...or,

The best practice of best practices is vetting the source of the best practice to verify its authenticity.

No?

> A best practice likely keeps you away from pitfalls known to the community of the practice but not to you.

In my experience, many "best practices" are the pitfalls you should be wary about, as they can easily translate into hundreds or thousands of lost hours of work and derail and doom entire projects. (The most annoying part of this is that the real causes won't be found, precisely because "best practices have been followed". Therefore the reputation of the best practice will stay untarnished).

Cryptography on the other hand is a well known example of something you should not touch at all unless you are an absolute expert- that's not even a "best practice" but probably the only reasonable practice.

I also read the language tutorial first. But if they don't explain their best practices (and often the explanation is simple), I don't care much for them.

I’m a bit confused with the analogy here. Would the non NEMA outlets work with my existing things or is the implication that they wouldn’t?

I could agree. It boils down to “you have to use your brain, and not try to invent and follow blind some rules”

They wouldn't, but about half of the developers commenting here would do the equivalent of switching from NEMA to something else on the grounds that the something else is better.

I don't mean tutorials, I meant guides. For example Go has guides on how to do something. e.g.: How to Organize a Go Module [0].

[0]: https://go.dev/doc/modules/layout