Recently I've been walking much more. To not waste time, I listen to talks from bookmarks from various conferences in headphones. It's funny that the more experienced I become, the more watery and obvious the absolute majority seems. Essentially you're already guided not by titles, but by the names of favorite speakers, much more reliable that way.
Yesterday I listened to this talk by PY from Square about runtime performance, generally very interesting and little understood, but one phrase from there caught me and I thought.
Best practices are the worst. They can be useful, but they incline people to focus not on their real problems, but on something else.
He's talking about some industry standards. Like do something this way or don't do something otherwise. He says this in the context of performance - no one will give you exact advice on what to do to fix performance specifically for you. But in general this applies very well to any problems. Obvious words, it would seem, we're often blinkered by what the industry says. We try to fit a square peg in a round hole, this forces us to solve problems of some completely different nature instead of just looking at our metrics and fixing what hurts in a specific place. I'll add that these best practices are often presented as some dogmas (yes, Google, I'm thinking about you), needless to say that this is bad?
Standards are useful, of course, in the sense that thanks to them some common language is formed, we can share these approaches with each other, people can more easily move between companies, but they should be some very high-level. We usually only start projects with something current generally accepted, but further and further we move away from this more and more, of course not forgetting to adjust to the market.
Standards at the project level are almost an absolute good. Standards between projects and generally between companies is to some extent a utopia. Best practices cannot always be the best. They need to be perceived only as another point of view that you take into account, nothing more. Projects are different, teams are different, tasks are different, "historical reasons" are different for everyone.
PS. As you understood, this is a regular reminder not to listen to some guys on the internet and think with your own head.