I've taken to looking at the first derivative of code quality rather than the zeroth. I don't necessarily sit and worry about the absolute, current quality of m

I've taken to looking at the first derivative of code quality rather than the zeroth. I don't necessarily sit and worry about the absolute, current quality of my code; rather, I strive to ensure that every time I do something, I'm generally improving the quality of the code rather than degrading it. If this sounds trivial, you may be underestimating the extent to which your fellow developers, and, perhaps even you, casually "spend" code quality to attain something in the short term. It's even little things, like adding the 7th parameter to a function that has become what really ought to be three distinct functions in one (very common problem). Adding that seventh parameter is degrading the quality of the code yet further. Working out what you need to do to extract the three separate functions out correctly, and propagating that back to all callers, is improving the quality of the code. We like to look at the sweeping refactorings, but a lot of times, it's very little things, as small as "Hey, I understand this variable better now that I've been in the function for the third time this month and it ought to have a better name, let me go ahead and use the IDE rename feature now". The quality of your code is much more determined by the sum total of all those little decisions than the big refactorings. You also don't have to "maximize" your positive impact at any given point and do all the possible improvements. That's paralyzing. Just make sure every interaction is just a bit positive, and the cumulative impact is huge.