I stay happy as long as my black box continues to function as advertised. That keeps me from obsessing over internal details. Ugly code can stay ugly and I sleep fine at night.
But whenever I wade into the code for good reason, I reward myself by refactoring whatever areas I happen to touch. It's like throwing a fish to a seal. That way I always get a chance to do fun things like unifying similar code or making code more data-driven.
I'm still a perfectionist, but I'm also a strategic procrastinator. So while I'm working on code, whenever I think of anything, however small, that might improve it, I'll throw in a comment such as "TODO 0703 might want to tighten this up" or "TODO 0703 you need to test this case before releasing". I am so relentless and unforgiving that sometimes the TODOs multiply like rabbits.
Before I release anything, I grep on "TODO". As long as any TODOs show up, I can't release. If I need to put off something until later, I'll change that "TODO" to "LATER". Occasionally I'll make a point of revisiting my LATER entries, converting some of them back to TODO. That way perfection is an ongoing process, not an attained state.
We actually did this on one of our releases. There was a task to scan the entire code base and either fix all TODOs or write a justification for why it could safely be ignored.
The problem I have with refactoring todos is that after a time it's no longer clear to me why the refactoring was needed (unless it's obvious, but in that case I probably already did it).
To be clear, I usually add TODOs only for observable features and enhancements, rarely for internal issues like refactoring. My point is that I usually refactor only when I'm already in the code for other reasons, as a reward for doing the immediate observable changes. This helps focus my refactoring efforts only on code that is already changing for the customer's benefit.
But whenever I wade into the code for good reason, I reward myself by refactoring whatever areas I happen to touch. It's like throwing a fish to a seal. That way I always get a chance to do fun things like unifying similar code or making code more data-driven.
I'm still a perfectionist, but I'm also a strategic procrastinator. So while I'm working on code, whenever I think of anything, however small, that might improve it, I'll throw in a comment such as "TODO 0703 might want to tighten this up" or "TODO 0703 you need to test this case before releasing". I am so relentless and unforgiving that sometimes the TODOs multiply like rabbits.
Before I release anything, I grep on "TODO". As long as any TODOs show up, I can't release. If I need to put off something until later, I'll change that "TODO" to "LATER". Occasionally I'll make a point of revisiting my LATER entries, converting some of them back to TODO. That way perfection is an ongoing process, not an attained state.