Now I just put a mental crosshair on the code I want changed and come back to it.
The number of times I've spotted some terrible bit of code then go through the version control system to try to find out more of why that moron did what he did only to discover that I wrote the code is embarrassingly large.
It’s the delusion that hurts.
Nobody is going to schedule time for integrity on the project roadmap. That's not how integrity works. You can find some or lose some, but on any given day you have it or you don't.
When hunting down a bug in bad code every method you read becomes a honey trap. It could be here, so you have to stop and grok this messy pile and that mental gymnastics removes parts of the todo list from your working memory. You pingpng around and when you find the problem you can’t remember why you were looking for it.
Then there’s code where you say “ugh”, take a breath and keep going.
If the smell doesn’t rise to the point of potential confusion about the purpose or goals of the code, if it’s a small inefficiency you can’t (yet) spot in the flame charts, then move on to bigger issues.
That said, I’ve paired to debug with people who defend their bad variable naming choices and the source of their problem was that their own code (and bad naming) confused them. You make them rename and they see the problem immediately.
My new motto is: filter out the reversible decisions and worry about the rest. When something in the former set breaks, make it a teachable moment.
In the long run ugly lines of code are so much better than a broken architecture or too much coupling.