I don't think you can move away from principles in general. The reality is that most SW design is subjective. Not reusing code is a generally good principle. It's just that the misapplication of DRY is following one good principle but violating another one (requirements should be decoupled).
In any case, the reason I go on the anti-rant rant each time is because when I use DRY appropriately, I don't want some idiot flagging me in a code review saying "Don't do this. DRY is bad. Here are N blog posts explaining why" - when none of the blog posts are complaining about what I am doing.
I don't think you can separate the principle from its misapplication. It's misapplied because it tries to stuff useful knowledge into a memorable phrase and the nuance is lost.
Flagging code in code review is another great example of harmful behaviour principles encourage. I've stopped referencing principles altogether in code review and I encourage others to do the same. Instead I focus on trying to explain the specific impact the code will have on our specific codebase.
> I don't think you can separate the principle from its misapplication.
In practice you are right, but this is just part of the human condition. There is no substitute for experience. Wisdom can’t be taught. The map is not the territory. Yada yada.
Principles still have value as short-hand for knowledgeable practitioners though. In fact, they have outsize value in this case because strong programmers will recognize and reflect on both the upsides as well as downsides discussed here. Communication bandwidth is the single most important thing to scale teams working on irreducibly complex domains.
I also sign up into thought school where “principles” went bankrupt. When I see someone quoting principle as a sole reason for code change it automatically shouts it is shallow explanation without much thought.
We could adopt a principle to solve this problem: something that reminds us that abstractions aren't free.
This is the source of the problem of the blind application of principles - which tend to increase the number of abstractions. They aren't free, and people act as if they are.
Even good abstractions have a cost. But in a good abstraction, the benefits outweigh the costs.
In any case, the reason I go on the anti-rant rant each time is because when I use DRY appropriately, I don't want some idiot flagging me in a code review saying "Don't do this. DRY is bad. Here are N blog posts explaining why" - when none of the blog posts are complaining about what I am doing.