Against Best Practices

> but because they’re mostly pounded by either 1) various types of zealots, idiots, and assholes who abuse these kind of “best practices” as an argument from authority, or 2) inexperienced programmers who lack the ability to judge the applicability,

The author might go on to make other points that are worth discussing, but lays out his supporting arguments clearly in the opening paragraph. Best practices do not necessarily do harm because they offer bad advice, they do harm because they are advocated for by zealots and the inexperienced.

My first reaction is how unfortunate it is that this particular developer has found himself in the presence of bad engineers and the inexperienced.

But then, the argument is automatically self-defeating. Why is the rest of the article even worth reading, if he states upfront what his arguments are and those arguments are very easy to refute?

It is deeply irrational to judge the merits of an idea based solely on who is advocating for that idea.

My advice to the author is to reflect on the types of positions that he accepts, the ones that have him so put off by the people that he works with that he is openly writing about abandoning what he admits could be sound engineering practice, solely based on who that advice is coming from and how it is being delivered.

Developing software is complicated. It is constant problem solving. When solutions to problems come about, and we abstract those solutions, it is quite easy for individuals to misapply the abstraction to an inappropriate concrete. To drop context and try to retrofit a lousy solution because that solution was appropriate to a slightly different problem. But at the end of the day, these abstractions exist to try and simplify the process. Any time you see a "best practice" or design pattern acting as a complicating force, it is not doing its job. At that point you can either be objective and exercise some professional curiosity in order to try and understand why the solution adopted is inappropriate ... or you can take the lazy way out and just assume that "best practices" are the opinions of zealots and the inexperienced who blindly follow because they don't know any better.

we don't have to give undue value to 'best practices', nor do we need to judge an idea based on its presenter. we just need to have a reasonable discussion about the idea in the context in which its being applied. this simple approach has been largely eclipsed in the industry by the fetishization tools, and the absurd notion that whole classes of approaches can be dismissed as being 'antipattern'.

It's not very hard to weigh a suggestion. speculate about its costs, benefits and risks.

> Best practices do not necessarily do harm because they offer bad advice, they do harm because they are advocated for by zealots and the inexperienced.

I think the point is that blindly suggesting "best practices" often is bad advice.

It's a common form of bikeshedding—it allows someone to give their casual two cents without doing the hard work of thinking through the tradeoffs.

I think the problem is that a lot of computer nerds are a bit OCD and like to apply one solution to everything. You see this with how they get crazy about strictly typed versus not strictly typed, one particular language for every application, or spaces vs tabs. I was like that when I was younger but as I get older I realized the world is the complex place and has programs have to deal with the real world there is no one solution fits all, or a best practice that always applies. To become good at programming you need to be adaptable to the problem space. Best practices are great for juniors once you've got a bit of experience you should use that instead.

My job revolves around adopting software solutions to solve practical problems and let me tell you, this mentality of one solution to everything goes beyond just the coding. I've encountered countless developers that seems to believe that the reality of a business should conform itself to how the developer believes your business/industry should operate.

Some of those fetishized tools are themselves anti patterns.

Funny, my experience is the opposite. When I was younger I thought there was a time and place for everything, a right tool for the job, a need to carefully consider the circumstances. As I got older I realised that actually a lot of libraries, languages, and communities are simply bad, and an experienced programmer is better served by having a deep knowledge of a handful of good tools and applying them to everything.