You're not weird. Or at least you are no weirder than me.

I sometimes enjoy refactoring more than writing new code. Deleting code, in particular, is pretty much my favorite professional activity.

Unacknowledged type-B procrastination? :-)

http://www.paulgraham.com/procrastination.html

Maybe. However, I haven't really regretted it yet.

I always regret type A. I do a lot of it.

I'd like to think I am pretty good at type C...

I do that all the time.

I like the Dijkstra quote: "Elegance is not a dispensable luxury but a factor that decides between success and failure. "

I also think it is a great way to become a better coder to refactor programs until you think it is perfect or close to rather than just make it work and then leave it because then you will never get better than that.

I do enjoy it, but as I gain more experience in building software for other people I have realized that they usually don't appreciate it. Corporate development sees this sort of activity as a liability. You can break things quite easily when you "correct" something. Poorly-written software tends to have tight coupling all over. Many parts of a system may depend on the "broken" definition of a function. Some things are just too broken to be tackled by this approach.

My current environment is much more receptive to this kind of activity, though.

+1 I'm on your side too. A benefit of "cleaning house" is that it does not take as much planning/thought as actually creating new code so this allows me to turn up my favorite music, get into a nice groove, and have at it...now that's what I call a good Friday night!

You are weird ;-)

I actually agree with the author on both points. There just isn't a good way of measuring how you use your time refactoring and cleaning code, when you could be fixing bugs or adding features (both of which are always-present).

Hence, it's difficult to justify too much time in "beautification" if your code works, even at competent shops. At some point, all of us just need to get the code out, so we must all strike a reasonable point between beauty and reality.

On the first point, I release a fair bit of code into the public domain. Even though I do make it nice and pretty as I code, it always takes additional beautification work before I'm ready to release it to the world (i.e. better commenting, code structure, or documentation). I'm pretty sure it takes a rare programmer with a lot of free time and great experience in the domain to actually have beautiful code at the conclusion of a project.

Constant refactoring makes it easier for me to add new features.

The first time I get something working, I often don't have the perspective to know how the best way to organize or abstract it. If I didn't go back and clean that up, it would be significantly harder for me to add on new features.

Well, Using Test Driven Development is a new thing. I find that using it, I now can clean-up code as I go along. I have one cycle for implementing new features and one cycle for clean-up currently. But it took learning TDD to be able to do that. And it took extreme programming for SOME shops to see the value in this. The trick is finding those shops.