This makes more and more sense to me the longer I program, and the few projects where I've been able to do it, are the few projects whose code still seems delig

This makes more and more sense to me the longer I program, and the few projects where I've been able to do it, are the few projects whose code still seems delightfully elegant to me. It is basically taking care of your "technical debt" before it becomes debt at all. (And I agree with other comment threads that it isn't always because of a mistake earlier, it's because the program has been called upon to do new things that weren't anticipated before, it's not so important to decide if they _should_ have been or not). But to do this requires a few things which can be rare: 1. Sufficient "Ownership" of the code to be permitted to do the refactoring. Like if you show up with a PR on an open source project that is new to you, to refactor to first make the change easy... it's going to go nowhere. Internal projects then will depend on the culture and social organization... 2. Time. If it's essentially eliminating your technical debt before it's acquired... well, the reason technical debt is acquired is because for better or worse, choices are made not to spend time on it, whether wisely or unwisely. 3. Skill. It's a craft. The more you do it, the better at it you get. Ideally learning by observing people do it who have already done it more than you. And it also requires having a general mental model of the existing architecture you are changing, which, first see #2 above, and second, can be hard to do if it's a mess. (Also, and this may be the most challenging -- with insufficient skill and sensitivity, your refactorings to "make the change easy" can actually make things worse, make your immediate change easy at the cost of a complicated spaghetti architecture which actually just over-complicates everything).