I'd argue that's the worst kind of best practice, because in order to get an entire team to work on it they now have no reason other than "their manager said so". It's one thing to skim over what you know your project manager won't understand (mine doesn't understand programming at all so really they just take our word on the implementation side of things), but to try and push it to the rest of the team and just hope they remember a long list of do's and don'ts without justification other than a book said to do it is stifling their personal development.

Even worse, if one were to go off and read up on what you've told the team to do on their own behalf, find that they don't agree with it, you've now got to handle: - a discussion that should have happened earlier - possible backtracking of recent work to try and reverse the pattern - OR a backlogged ticket to reverse it while the system now has multiple different patterns sitting around with no push for consistency in either direction due to lack of priority

Obviously becomes much more of an issue the larger the system is, but in general you shouldn't be following (or asking others to follow) best practices without knowing the benefits behind them versus what you're doing now.

> One of the key benefits of "Best Practices" is, when provided by the documentation of something you're using, you can reliably consider it as good advice and follow it, even if you don't necessarily understand why it is the best practice.

If you don't understand why it is a best practice, you cannot reliably consider it good advice (though, sure, you can cargo cult it anyway) for your use case. Even if the source of “best practices” is reliable (and many are not), if you don't have at least a basic understanding of the rationale, you don’t have any idea if your use case is in the neighborhood where you might need to dig deeper when considering whether it applies or is counterproductive.

I get that lots of people do use best practices this way, and feel reassured that sone authority said so for reasons that remain murky and unexplored, but this is absolutely the worst possible use of “best practices”.

> my project manager asks me why we're not using sequential IDs, and I say it's a best practice according to the documentation, he'll happily accept that answer even if neither of us understand why it's a best practice.

I have to say, I think I would be happier with an answer like "because it avoids hotspotting according to the bocs"

This limits the applicability of the "don't use sequential IDs" rule to where it actually helps.

Otherwise, the rumour spreads, and later you find teams doing huge damaging work arounds to avoid using sequential IDs, in contexts where hotspotting is totally irrelevant (perhaps because they are not even using Firestore) all blissfully unaware, because they they think they are following "best practice"

I've seen this happen so often in large companies, the words "best practice" let people abdicate their professional responsibility to _think_ and it's quite dangerous IMO

I have seen plenty of instances where people write documentation in which they label something as a best practice, even though it's just something they preferred to do and weren't really able to articulate the reasons for, unfortunately.

Yes a lot of people like to be the person who says what the "best practices" are (even or maybe especially if they've just made them up) it sounds much more impressive than "I like to do it this way"

A “Best Practice” that doesn’t spell out the pros/cons of applying the practice, and the contexts where it is applicable and where it isn’t, is not a useful “Best Practice”. Blindly doing something you don’t understand is not recommended. Ask hard questions!