While that's true for me to some extent, but what I also noticed is that I really like doing is building things. When I'm not coding, I woodwork, build RC airplanes, or find something else to work on.
Fortunately, there exist many someones that do like writing things like XML parsers, so I don't have to be one. I think that might be Wolf's point.
I know for a fact I hate drudging through writing custom classes, I've said it before and I'll say it again, when I'm doing tedious repetitious coding of things like a parser, I tend to start feeling like a glorified data entry clerk.
but when it's time to see that parser in action and use it to solve real problems, especially by many different applications, THAT is the reward.
I agree there. I use power tools, but I don't build them. OK, I think about building electric motors sometimes, but I haven't tried yet. What I really want is a nice table with tapered legs, so I use the best tools I can get to do that job well. Someone else might use the table to help them build something else.
It's the same with code, we keep builing things and sometimes those things are used to build something else. Sometimes that's obvious, like libraries or frameworks that are dedicated to being part of some other software solution, but often the softare helps someone build something else that isn't software.
I ask because the master woodworker I took my one class from had a library of custom jigs. He was also amazing to watch, even when planing a board. Confident and skilled. His passion was making shaker-style chairs. Chairs are hard to make because they have to be constructed properly (so many external stresses from people sitting in it, rocking back etc.)
I loved his philosophy of there is no right way to do something (in the woodshop) - only smarter, faster, and safer. And how he revealed the secret of shims to make a joint snug.
I could go on and on. Suffice it to say, you can learn a lot by taking a furniture making class, taught by a master.
One thing I've learned is that there is indeed more than one way to build something. I've been able to take advantage of that when I didn't have the tool a project used, but knew how to get the job done with another.
It's much the same in software. There are many different ways to get the job done. Some tools are certainly better for a job than others, but often one can cut something two different ways and still end up with the same result.
If he said "programmers don't like to write code that's not directly related to the problem they're solving," I'd agree. But if that's what he meant, then he should have said it.
I find the practice of starting out with a provocative statement, then redefining the semantics of the discussion until the unqualified thesis statement is true both annoying and disingenuous.
I think it's accurate to say "I like to program" because it goes beyond problem solving for me. I enjoy solving the problem, yes, but I also enjoy expressing the solution. I enjoy the process of figuring out what is the most concise, elegant and natural expression of the solution, and I find the result pleasing.
I agree with your post wholeheartedly and on all accounts. You don't get readers without starting some arguments, though.
It's that judgement call.
I've just written a DNS client, because I needed to. In the process though, as well as having a very cool DNS client I know will work, I've learnt about the DNS protocol.
Thank god.