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.
Amazing what you can find when that happens :-)
Most terminals and monitors today will easily go to 100 chars, which is typically where I prefer to break lines. This gives room for 3-4 levels of nesting (using 4 char tabs), which is about the max depth you'd want to nest. There are exceptions of course but for the most part any more than 3-4 levels deep and you should be looking at refactoring.
Then a new member came to the team, and his coding style was not very good. I told him to read and follow PEP8, he downloaded some script which checks source for PEP8 compliance, and he really made the effort to format his code.
So, it's not something that I would personally go insane trying to keep width to 80, but when two things happened: I was already doing most of the PEP and my teammate wanted me to keep 80 chars, and I had to eat my own dogfood :) when the new person came on board.
In the end, it's something easy to do, and keep my colleagues happy.
Great point. By not having customers right now, I've likely started to overvalue my own development/investment.
But I don't go actively looking for things to "fix". While reading code, if only one line is separating functions, I add another. I add \ to line ends trying to limit width to 80 chars.
Lately my mantra has been "Shipping is a feature". Code working is my number one priority. But like most of the people, I like to think I'm above average, so I don't believe I write _bad_ code at the first time. I know it's not perfect. Just by saying this, I remember of things I know I should change to make the code better, but why bother?
What you must always pay attention is the balance between creating value for your customer, and for you as a professional. And even when you do things for yourself, always remember your main objective is to make things easier in the future to create value for your customers.
Caveats apply, of course. A refactoring to allow more modularity or whatever in the future might be good to do now, but honestly usually there are more pressing matters (unless the current pressure is to add some module functionality).
It's hard to give any straight answer. There are no hard rules, like "you should only refactor during one hour per-day". Maybe you're doing something where a big-design-upfront is not possible. Maybe not.
These things come with experience, tough. And where you want to keep your focus. If I was working on a 10 year code base where the original programmer has left the company, and didn't document anything, then I guess I would spend more time nurturing the code. But my job today is too fast paced, and "when it will be ready" is my customers/stakeholders number one priority. I negotiated and told them quality would suffer, and they are aware, but don't care much.