Welp, I've finally figured out what kind of programmer I am: a perfectionist. Okay, not technically a perfectionist, but I do prefer for code to anticipate itself becoming perfect rather than to be shooting for anything less. If, at some point along the way to becoming perfect, the code is in a testable, usable state, ship it! But if it's going to take the same or less time -- heck, if you're going to pour anything resembling half the time into a short-term, non-permanent fix -- to solve the issue you're introducing with a shortcut to get back onto the road to perfect, I'd prefer to make that change now.

Now I'm not freakish about it. I understand goals change and you have to back up and say, "We were headed towards point A, but now we've decided, for good reasons 1,2,3, to swap our direction to point B." That's fine. But I can't stand huge detours to point C where you still outwardly claim you're headed towards your original goal. And if you swap goals too often, well, I hate that too. ;^)

Factoring code might seem "as much art as science", but it's all logic. And, as a coworker once said, "I can hit a moving target, but I can't hit a moving target in the dark." Change goals, but warn me and tell me what's out there so that the code's ready to achieve 'em from day 1. Nothing worse than ripping up work due to poor planning.

Which brings me to the second part of being a perfectionist: I don't like shipping crappy, hard to maintain code, even if it does exactly what it's supposed to. Short-term-goaled managers hate me. Long-term-goaled managers love me. Realistically-goaled managers aren't real sure, but at least know where I stand. You must QA your code, and I mean the innards as well as the outards. If you're taking a shortcut when coding, comment why. If it's going to take longer to comment and explain to the next guy than it would take to Do Things Right, well, Do Things Right, dangit!

Perhaps that makes me more an idealist than a perfectionist. Anyhow, rant over for today.