[TehShrike]

I think it is best to strongly reject the idea "best practices will always benefit you".

Most best practices that I have been told about were low local maxima at best, and very harmful at worst.

If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it.

It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason (not a "just so" explanation that skips several steps).

[lmm]

> It might still be a good idea, but you shouldn't seriously consider it until you hear an actually convincing reason (not a "just so" explanation that skips several steps).

If everyone follows that then every decision will be bikeshedded to death. I think part of the point of the concept of "best practices" is that some ideas should be at least somewhat entrenched, followed by default, and not overturned without good reason.

Ideally your records of best practices would include a rationale and scope for when they should be reexamined. But trying to reason everything out from first principles doesn't work great either.

[trelane]

It strikes me that, if a decision can be bikeshedded to death, it's not, generally speaking, an important decision.

[lmm]

Well calling something a bikeshed is implicitly claiming that it's not so important. Often the specific choice is not very important, but making a choice rather than not making one is important. And while an effective organisation would not allow important decisionmaking to get derailed, many organisations are ineffective.

[KronisLV]

> Most best practices that I have been told about were low local maxima at best, and very harmful at worst.

This matches my experience, though sometimes they indeed will be helpful, at least after some consideration.

> If someone quotes a best practice to you and can't cite a convincing "why", you should immediately reject it.

In certain environments this will get you labeled someone who doesn't want to create quality software, because obviously best practices will lead to good code and not wanting to follow those practices or questioning them means that you don't have enough experience or something. Ergo, you should just apply SOLID and DRY everywhere, even if it becomes more or less a cargo cult. Not that I agree with the idea, but that way of thinking is prevalent.

(not that I agree with that, people just have that mindset sometimes)

[TehShrike]

I agree with you, I think you're describing the same sort of person I was thinking of in the second paragraph of this post: https://joshduff.com/2022-02-07-eschatology-of-software.html

[Aeolun]

Hmhm, just like “AWS is recommending serverless, so we should serverless everything!”

Never mind that AWS recommends what is good for AWS, not us.

[agentultra]

I definitely sympathize with the thrust of the article. I think the reality is somewhere in the middle: best practices are useful short-cuts and people aren't always idiots for suggesting them. I've worked with folks who insist on Postel's law despite security research in recent years that suggest parsers should be strict to prevent langsec attacks, for example. In those cases I would refute leniency...

Although I also do work in fintech and well... card payment systems are messy. The legal framework covers liability for when actors send bad data but your system still has to parse/process/accept those messages. So you need some leniency.

It does drive me up the wall sometimes when people will hand-wave away details and cite maxims or best-practices... but those are usually situations where the details matter a great deal: security, safety, liveness, etc. People generally have the best intentions in these scenarios and I don't fault them for having different experience/knowledge/wisdom that lead them to different conclusions than I do. They're not idiots for suggesting best practices... it's just a nuisance.

That's what I mean about the rejection being too strong. It should be considered that best practices are often useful and helpful. We don't have to re-develop our intuitions from first principles on every project. It would be tedious to do so. But a healthy dose of skepticism should be used... especially when it comes to Postel's Law which has some decent research to suggest avoiding it.

[0xbadcafebee]

I don't think anyone has ever thought that best practices will always benefit you. Nothing always works every single time in every single case.

This whole thing is really silly and obvious.

Of course you shouldn't blindly follow advice without thinking. But not following advice just because it might not always be right is also a bad idea.

My advice: In general, you should follow good advice from experienced people. If enough experts say this is the best way to do something, you should probably do that, most of the time.

But that advice will never trend on HN because it isn't clickbait or extreme, and requires using your noggin.

[TehShrike]

> I don't think anyone has ever thought that best practices will always benefit you.

Whenever a "best practice" or "convention" has been presented to me, that is how it has been framed. (...it is best practice, therefore, it will definitely benefit you to follow it)

[davorak]

I do not know what context this happened to you in, but in the context of building something quickly, learning, while not being an expert in an area, best practice are a common crutch.

In many work places either they do not have time or at least think they do have time to think things through 100% for themselves from first principles so they depend on best practices instead.

That makes sense to me and I would expect better results on average with using best practices than rejection of best practices in the above context.

That said I try to work on things where I am not always in the above context, where thinking things through end to end provides a competitive advantage.

[agentultra]

100%… a best practice in other traditional engineering practices help us work within the state of the art. They’re the accumulated wisdom and experience of engineers that came before us.

There are plenty of them that help us write concurrent code that avoids common deadlock situations without having to resort to writing proofs every time. Someone already did the work and condensed it down into a rule to follow. Even if you don’t understand the underlying proof you can follow the rule and hope that everything will shake out.

What I find we struggle most with is knowing when we actually need to write the proof. Sometimes we bias ourselves towards best practices and intuition when working it out formally would be more prudent.

[Aeolun]

In general that is true, I think. Even if it doesn’t apply in all circumstances, it’ll apply in most.

It’d be ideal if you could identify when it doesn’t work. But in the absense of that applying it everywhere is still a net positive.

[0xbadcafebee]

I could tell you the moon is made of cheese. If I'm wrong about it being made of cheese, does that mean the moon doesn't exist?