"Programmers don’t like coding, they like problem solving."
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.
Right, but you don't plan on making your own glue before doing woodwork, right? It's the same thing - I don't want to write an XML parser, there are tons of them. I want to build something exciting to me.
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'm not sure what his point was, because he kept sticking to the provocative "programmers don't like to code" line.
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'm always on the lookout for that sort of thing too, but I don't think you're right here. I get annoyed when people say "ellyagg likes to program" because it's dismissive, like I'm some strange creature who finds the task of putting various glyphs in parallel lines soothing. I don't enjoy programming for programming's sake. I enjoy creating and I enjoy my creations bringing value to other people's lives.
I guess I don't interpret "like to program" that literally.
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.
The someone who wrote that XML parser was likely also trying to solve a problem, and not just for themselves, but for many.
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.
That's true, but I made that statement about XML parsing based on my own life experience: I love working on version control tools, I'd work on them even if nobody else used them. They have this internal beauty to me, but most people have just decided I'm a little nutty for liking that kind of work.
You are in fact nutty, but are still trying to solve a problem no? Sometimes we solve problems because the solutions are useful, and sometimes we solve problems because the problems are interesting. I think most of my personal coding falls in the latter category.
If an XML parser is really important to what you're doing, then definitely go ahead and write one.
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.
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'm curious. In your woodworking practice, do you use/invent custom jigs to make some of your construction/cutting process faster? What types of projects do you enjoy making?
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.
You know, I thought about jigs as being sort of like software libraries. I've made jigs for specific projects mostly, but I've made a tapering jig for my table saw and an extension table for my miter saw that I've reused.
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.
I think many of us fall into the same boat. I know that as a younger child, I loved to build with blocks, Legos, and Knex. While my tools have changed, it is the same desire to build that gets me excited about programming.
"If programmers liked to code, they wouldn’t value a language by its libraries."
Yeah, that's why I spend 16 hour days coding in Common Lisp and Mozart/Oz.
"If programmers liked to code, every last one of us would be overjoyed to write our own HTTP client."
Because HTTP clients are a stupid display oriented and bug-tolerant little things. HTTP SERVERS on the other hand, those are more tractable, since you can be responsible for following the specs yourself, and a treat to work with for all the interesting engineering possibilities they offer, which is why more people have written web servers than web clients.
“I just want to update this field in this file, why do I have to write an XML parser?”
Oh, he is talking about that programmer: the corporate data janitor. That sentence is just laden with idiocy; first, if your data is in xml and you don't have established tools to perform "CRUD" type operations on your XML files, you're doing XML wrong (lack of established process). Second, if you have to write an XML parser to edit an entity in a file, you're doing it wrong (refusal to use established tools, NIH). Third, if someone has to enlighten you on how to update one of your data files (inability to RTFM) .. Dear Neo, the salve of Hackingkind, you're doing it wrong. No wonder you hate programming then.
I've always thought that coding kind of came with the job. I don't like repetitious tasks in my coding life any more than any other, but I still enjoy the man vs machine aspect of coding.
And since when did 'Programmers' become such prima-donnas? I like whatever it takes to continue a career in developing software, sometimes that means tedious stuff, and sometimes really interesting ah-ha moments of coding.
I wrapped my web app with an error handler that sends an email to myphonenumber@bigtelco.com and I get a tidy tiny error report as a text message, wherever the hell I am.
When you handle certain kinds of data, you're required to take maximum possible care to ensure secure and continuous operations of the system, and the steps you have taken towards that end.
There are clearly different types of programmers. For me I think it would be more that I like designing and seeing concepts become something. Some people don't get that programming is actually a very creative process.
There is some problem solving, but if it was problem solving that I enjoyed I would have enjoyed math (more).
I think a large percent of programmers want to rewrite things because they focus on what's lacking in some way, expect to do everything better than the next person, it's easier/more fun/feels more productive to write than to read/grasp other people's code etc....
He quoted Andrew Leonard quoting Larry Constantine but took a light-hearted sentance and seems to deliberately misunderstanding or taking it too literally.
But the rewrite/reuse issue needs to be addressed in a per-case basis... but I've seen thing beeing rewritten way too many times that should have been reused and usually ending up in much worse shape after that....
Although, I've also seen rewrites that improves stuff a lot.. but usually it's very very obvious when that's the right action to take.
Considering it's the basis behind science and pretty much all analytical thought, can we please stop pretending making generalizations (yes, even big ones) is a bad thing? This generalization was interesting and contains a large degree of truth; if you'd like to disagree with that, or explain where the generalization falls down, do so.
The basis of analytical thought is testable predictions.
Counterexample to "Programmers don't like to code" :
I am a programmer, sometimes I like to code.
Sometimes I like to code in C. I like to implement some basic objects, like a list, a stack, some math routines. It is a like a little zen garden. So it isn't anything impressive, it's just like some rocks and sand, but I arrange it in a certain way and I like it.
Maybe I should address the content rather than the title (although if the title fails to represent the content it is a poor title.)
"Programmers like problem solving" is the kind of vague positive statement that is pointless and devoid of content. Here is a problem I don't like to solve: configuring Apache . . . yawn.
When you talk about likes and dislikes, generalisations do really fall down. For example I have indeed seen code rewritten from scratch because the programmer did not want to spend the mental effort to understand it and liked doing their own thing. I have also seen code re-written from scratch under the greatest reluctance because the original code was so broken.
Generalisations are all very well when they have something to teach us. In the article's case neither the thesis nor the counter-thesis seem particularly illuminating to me.
>> "If programmers liked to code, every last one of us would be overjoyed to write our own HTTP client."
Writing an HTTP client, and server is actually something I believe every one of us should do. As well as providing you something useful, tailored to your use case, it teaches you a massive amount about how everything works. It's pretty much definitely good fun :/
(I wrote both of these, and a dns client, etc etc for Mibbit).
I'm utterly lost when it comes to all the categories of coder, engineer, programmer etc. I tend to think of "people who write code" as all being in the same bucket. How well you do that just makes you a better or worse "person who writes code" rather than putting you into different categories.
There are probably some reasonable categories in there, but I would say they are more like "algorithmist" (more mathematically inclined), "systems developer" (more hardware oriented), "application developer" (more user experience oriented), etc.
I'd argue that there are a lot of different breeds of programmer who fall at various points on this spectrum. Some programmers like to rewrite things because they are perfectionists, other programmers find any working code (for some value of working) to be "good enough" and move on. Many programmers don't fall neatly under any single label.
In particular his distinction between a preference for "problem solving" or a preference for coding obscures a much richer diversity of attitudes. An understanding of the subtle gradations between these various different kinds of programmer is probably one of the best tools available to the truly thoughtful software manager.
Personally I am really only enjoying myself if I'm tackling a "hard (for me) problem", if the ratio of typing to thinking is high then I'm "working".
after ... building it, ... they’ll understand the whole.
While I agree that understanding is a motivation and that building it does help, as your ideas become more complex, just being able to code it does not mean that you understand it perfectly.
My coding thrills are for understanding, for automation, and for impact (including the childlike-joy of just seeing something happen when I do something).
For me, the PC is an experimental lab. I can quickly test my hypotheses; and get fresh data, which inspire new hypotheses. The PC is a means, not an end.
Indeed. I like writing code, but I dislike writing more code than absolutely necessary to solve a problem.
Also, this might not be relevant in this case, but I feel like there's a difference between "coding" and "programming". In my mind, coding is a dull task of translating an existing design into code, whereas "programming" is more problem solving, which includes coding. Being called a "coder" is almost derogatory sounding to me.
Often, yes. Reading code very rarely induces me to understand what I'm reading (and I'm pretty undisciplined, so rather than being able to force myself to think deeply about it, I often just reread until I "get" it). However, figuring out how to build something like it myself promotes understanding much faster, in my experience.
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.