This attitude, it turns out, is hard to kill. I see it in others, and I see it in myself, although I should know better by now.
Some of my habits help fight this. I generally write small functions. My code is functional whenever possible. Scope of variables is small. Globals are rarely used. These habits help, but they still don't cover everything.
The main question is... "Is the code understandable? To someone who hasn't been hacking at it for a week?"
Maybe like editing a paper, these questions need to be asked after a day or so or writing the code, so that the eyes are semi-fresh when looking at it. Certainly a different set of eyes looking at it would be even better.
Most of the good practices (I mean the really good ones, not just the popular ones) work towards making the code more understandable. Even some of the other good goals, like managing complexity, seem secondary to understandability. Managing complexity is necessary, but not sufficient to the goal of clear code.
When coding, it is very easy to just be done with something, without even a cursory check of how good it is. So, how do I establish that habit? I probably write more code at home, for fun, than I do at work. That is probably where I need to build the habit, but it hurts a little to think of doing that extra effort for code that no one else will ever see, and that I might not ever look at again.
The habit may be worth it though. Clearer code is more likely to be right, or at least easier to get right, instead of wading through the muck of something less clear. Like clear writing, clear code should also encourage clear thinking.
That is a new goal of mine. Let's see if it sticks.