Yes.

All rules and idioms are rules of thumb, useful for making quick decisions. All of the rules have exceptions. You are becoming a senior developer.

If you're talking to someone who thinks you should always write tests, always DRY, everything should be OOP/Functional, then you're talking to a junior Dev.

When best practices are evangelized, often the context in which they're great is not.

It's like any list of rules (e.g. rules for slidedecks) -- great for beginners, perhaps good for consistent team standards. However, once you understand why the rules exist, you also know when to break them.

I thought a great talk around this area was Engineering You by Martin Thompson [1]. He used the phrase the "era of Software Alchemy."

[1] https://m.youtube.com/watch?v=S4LzzuMTqjs

Developer strength matters more than most other factors. A strong developer will run circles around a weak one even if the former is programming in assembler and the latter in Python. Thus studying variables such as programming language is difficult and costly because the variance is enormous. Therefore it is not done and a result like web developers are on average more productive in Python than in assembly is probably not that interesting anyway. Thus we are left with "truths" there is no scientific basis for.

Yes of course! What works for one group of developers might not work for another group of developers. The projects and experience levels in this industry are too varied to make one-size-fits-all work.

So any practice/idiom that doesn’t carefully spell out the context in which it works should be ignored or at least treated with caution.

And any developer who makes claims about X being “always best practice” or “always best solution” are basically self-identifying as inexperienced/arrogant/not-smart/treat with caution.

Part of it is that software is not a single community of practice.

Unlike other fields of engineering (or medicine, or hairdressing, ...) there is no meaningful certification or regulation of the field.

Circa 2005 you had people who would do it the Microsoft way or the highway who thought open source software was a joke. There are still people today who think you're an idiot because you have anything to do with Microsoft.

Frequently one hears bombastic comments about programming languages. For instance, "Java drools, Haskell rules".

Many people think that there is some practice that applied dogmatically gets great results. There are many ways that people resolve that contradiction, one of the most interesting is widespread "normalization of deviance".

It's not unusual at all to join a new team and get told that "we write tests for everything", "we always do code reviews", and have the engineering manager describe a number of practices that are used consistently. When you look at the code you see that test coverage is maybe 5%, the practices that are allegedly being used are not being used, and come to the conclusion that we must not be doing code reviews otherwise we'd be doing what we say we do.

What is very visible to me (in the industry for about 35 years now) is that most people today only know 2 platforms: Unix and Windows NT.

They are, considered in context of the rest of the desktop personal computer industry, nearly identical.

But we had a mass-extinction event in the 1990s and most people under 50 haven't seen anything that is actually _different_.

So, for instance, people think that C is some sort of universal assembler and everything else is built on C. This is not even adjacent to something similar to the truth: it reflects the blinkers of the 21st century PC world.

I'm not sure about most, but a lot of them are. Wisdom is knowing when any given practice should be applied. I think this is true for many fields and disciplines.

I think it's more that the best practices are situational. Software development is a very diverse field, so it's hard to make any universal statement.

Yes, you have a brain.