Do programmers like coding for its own sake?

This from Andrew Leonard interviewing Scott Rosenberg:

And programmers, as I quote Larry Constantine in my book, programmers are programmers because they like to code — given a choice between learning someone else’s code and just sitting down and writing their own, they will always do the latter.

Jonathan Rentzsch responds:

Summing up: programmers don’t like to code, we like to solve problems. Coding is not problem solving, but software problem solving usually involves some coding. Even when we talk about rewriting something, the objective is not to code, it’s usually to get a better understanding of the problem for solving in the best possible manner.

I think the truth lies somewhere in the middle. I have worked with programmers who, asked to write a feature, never even look at a language’s class library before hacking something out themselves. They like to code for the sake of coding. There are are also programmers who would rather code than learn. They rarely adopt new tools and they don’t pick up new libraries when they’re released.

As a programmer, I’d prefer to do as little programming as possible. I try to make use of libraries when they’re available and to find the best tools possible in order to help me avoid both coding and debugging. I like working with programmers who work the same way, because maintenance is rarely any fun.

That said, even the best programmers often write more code than they need to because it is easier to write code than it is to find what you’re looking for in someone else’s code, or even in your own old code. At the atomic level, there are convenience methods. Let’s say you have an object of one kind that shares some of the same properties as an object of another kind. For example, you might have an incoming HTTP request with parameters that need to be copied into an object that’s stored in a database. One day, you write a method that copies all of the values from the request into the persistent object, you use it in one of your classes, and you check it in. Are the other people on your team going to know you wrote that method and start using it? Probably not. It’s simple to write so they’ll probably just write their own version of it. Knowing myself, chances are I might not remember I wrote that method a few months down the line and rewrite it later without thinking about it. That’s the life of a programmer.

This happens all the time at many levels, from convenience methods on up. The tonic for it is good refactoring tools and good test coverage. The best way to reduce this redundancy is to surgically remove it whenever you see it later. If I’m fixing a bug in the class with the redundant code, I may realize that it’s redundant (or at least that I’m doing the same thing in several places). A good programmer will refactor their code to eliminate the redundancy, and the key to being able to do so is having enough tests to make sure that the refactoring doesn’t break things.

In an ideal world, nobody writes more code than is necessary, but complexity is the enemy of that ideal. The key is to build the habits and use the tools that let you work back toward that ideal to keep things as clean as possible.