It's always been programming as a craft to create something of beauty vs. programming as an engineering pursuit to produce something that solves a problem. Som

It's always been programming as a craft to create something of beauty vs. programming as an engineering pursuit to produce something that solves a problem. Sometimes they overlap, but folks like UCB, DRY, SOLID, TTD, whatever the oft repeated mantra / person, miss the forest for the tree. Define your goals in terms of how you'll solve an actual problem: "Implementing this new abstraction to follow DRY reduces the time it'll take for a new feature to be added since it encapsulates X, Y in a higher level interface and reduces boilerplate code". Great, go for it. I refactored half the project to remove 3 lines of easy to find but copy and pasted code? Not so great. It is the difference between a junior and a more experience programmer. How does this >thing< you're excited about reduce code entropy, increase confidence in correctness, make it faster to iterate on the code in the future by other developers? That's mostly what I care about. The >thing< can be a language, library, framework, design pattern, etc. that you read about. Of course in specific cases you'll have performance, strict correctness, security, etc. that you're also solving for that's factored in.