I read Programmers Don't Like to Code a few weeks ago and spent some time thinking about it before wanting to comment. There is much to like in the article yet I'm not sure I can really agree with the title.
If you ask any real programmer want they like best about the things they do, most will tell you "I like to write code". Virtually no one will say "write requirements", "test plans", "go to meetings", "fill out status reports" or even "draw UML diagrams". Anyone who does enjoy these things more is highly unlikely to remain a programmer and would probably be happier as a project manager, architect, QA engineer or CEO.
Programming of course is more than just coding; we all have to do other things sometimes. The core reason for our existence as programmers remains telling the computer what we want it do to, which is coding. Building requirements (what do we want to tell the computer to do), architecture (how to approach telling the computer what to do), testing and QA (making sure it does what we want it to do) and meetings (trying to agree on who's fault it is that the computer isn't doing the right thing) are all additional tasks that make up a programmer's life.
Ask a real programmer and it's always about the code. Nothing else actually matters since it's the only thing that actually runs on the computer. The computer really doesn't care squat about requirements or pert charts or the color of your bike shed. It just does exactly what you tell it to do. Sometimes it doesn't do what you want it do and it's all about the cursing.
I can agree that programmers view coding as solving problems (although some managers would believe programmers use code to create problems), but without the coding there isn't anything interesting to solve (how long do we wait at the start of the meeting if the manager doesn't show up right away before leaving just doesn't cut it). If solving problems involved coming to work and pushing the red button to generate all of today's code would that make us happy? No. Coding is an art, a creative effort, an exercise in imagination and a joy when something works well. It's a mental challenge that few other professions can match, and only a small percentage of the population has the right mentality (some might say insanity) to do it well. Programming without coding is like non-alcoholic beer: what's the point?
I believe a programmer can like coding and still prefer languages and frameworks and tools that make it easier. We don't just want to code less, we want to spend more time coding the important stuff, the meat of the problem. We want to get the code to the computer and see it working now and move on to the next challenge. We want to code without spending lots of time writing peripheral stuff, like XML configurations and MAKE files. Well, there are some people who like those. Scary.
We don't want to write yet another web application framework, unless the problem requires it. If it's important to get to the real problem we will use one that's handy. If there is something to be gained by writing one we will do that too. We want to solve the problem or provide the service or whatever the task is in the best way possible. That's what a good programmer does.
A lot of companies and managers like to fill the programmer's life with lots of other stuff, like meetings and status reports and requirements analysis and writing test plans and fighting environment issues and begging for decent computers. But programmers don't like to spend any more time on any of these and will actively seek ways to avoid them and get back to coding. So good managers know this and will protect them. Sadly I have known few people who were any good at this; often they used to be programmers too (probably never liked to code either). If you find one let me know.
It's possible that programmers can like to code so much that they rewrite everything and write way more code than necessary for the shear fun of generating piles of steaming crap. Good programmers like to code efficiently and effectively. If you want to be a good programmer you have to want to learn new technologies, new patterns, new techniques, and new caffeinated beverages. Coding well means coding intelligently and being able to separate out the stupid new things from the truly useful. Solving problems through code does sometimes require that you write very little code.
A friend from a long time ago worked on some of the original 911 code and related a story where he was asked to figure out later how to add a complex feature required by some federal agency (I don't recall the details). He stared and played with the code for months trying to figure out how to add this feature without breaking the rest of the system. Eventually he only wrote a few lines of code to implement it, but they were in the exact right places where it worked perfectly without screwing up anything. That's still using coding to solve a problem. From a manager's perspective he looked like a slacker.
So if you meet a programmer who doesn't like to write code, be very wary. He might be your manager soon.
And then you have a problem you can't solve with code.
Peter Bona 02/27/2007 05:13
You are both right: Programmers like problem solving. Currently the best tool to make a computer do something (solve a computer problem) is coding. So programmers do like coding. But if a new tool or way emerged by which one would be able to solve computer problems without coding (which, I think, will never happen), programmers would like that too.
Recently I have seen someone who was as exciting about defining business processes in XML which would solve her problems as programmer about coding. She did not consider business process XMLs coding but I think it was in a way. It was really about problem solving.
The Fat 02/27/2007 05:20
I used to be a programmer once....loved the coding, hated the meetings. So I quit it as a career, and do it as a hobby every once in a while. It's a lot more exhilarating when you don't have a blithering idiot for a manager breathing down your neck.
Snappy 02/27/2007 07:38
Right on! I'm a coder myself and boy do I like to code! 8)
skippy 02/27/2007 08:02
We have a guy who sits in the corner, working on a framework we are supposed to use. He doesn't like doing design docs. He doesn't like discussing design with the programmers who will have to use his framework. He doesn't like talking to subject matter experts about what facilities the framework should provide. He doesn't like walkthroughs or peer reviews to spin people up on his code. He doesnt like writing interface deinitions for his framework. So he doesn't. He likes to create source code files. Question 1. Can he possibly be a good programmer? Question 2. Would you like to have to use this framework? Question 3. Would you like to maintain his framework?
Geeee 02/27/2007 08:07
"the Fat", what do you do now?
I think there are a few careers out there that challenge the brain the same (or nearly) as programming. Architects, medical/pharmaceutical research, being a CEO too. As stated above, it is about solving problems. Programmers use code, architects use math, etc...
So, if you did not code today, what would you be doing? I always thought I would be a good architect. Just call me Mr. Brady ;)
BojanP 02/27/2007 09:52
Only on the subject of brain utilisation and jobs. The highest ever recorded level of brain activity happens to occur with concert pianists. (and pianists in general also - think about it - synchronising 10 fingers and 2 legs, not only as regards their positions but also on the minutest differences in velocity etc., whilst expressing emotions without words - sounds quite amazing, huh)
Charlzz 02/27/2007 09:53
Although one can say programmers like to solve problems, it's not the only trait that makes a good programmer. For example, there's plenty of mathematicians who like to solve problems too, yet many do not like programming. Why not?
There are several reasons. First, there is no ONE TRUE PROGRAMMING LANGUAGE(TM). Every few years, a new programming language comes along (Lisp, Fortran, C, C , Java, Python, Ruby) and a programmer that wants to keep up must extend their toolkit, often in ways that do not immediately create productivity. Mathematicians, on the other hand, can, more or less say that their system of proof has basically remained unchanged for hundreds of years. This allows them to focus on actual problem solving (or writing proofs).
A mathematician would look at a programmer and wonder why they should bother learning Java as it is a passing fancy, filled with arcane details, and ever evolving (we're up to 1.5).
A good programmer is, much like fans of fashion, someone who tries to follow trends, which means they must determine what are the important trends to follow, and then try to learn them. With the proliferation of technologies, there are some technologies they must decide not to learn.
Much of what makes a good program is not written down, or at least, not taught in the textbooks. I once taught with a colleague who still was talking about top-down programming from back in the 80s. She wasn't aware of design patterns, and even if she had been, she might have thought it a trend.
All this suggests that programming is still evolving, and that we haven't gotten it right yet and may not for some time to come.
Edward S. Marshall 02/27/2007 11:17
Charlzz: I think you've hit on a good point, and it's what I like to refer to as the difference between Programmers and Computer Scientists. A computer scientist isn't interested the language-de-jour, they're interested in the algorithms, mathematics, and underpinnings of what eventually becomes programming as a trade.
A computer scientist makes a lousy programmer, in most cases, because trade programming has a completely different set of "desirable" skills: project management, group dynamics, non-programming subject matter research, meetings, deadlines, and business pressures all play a part in a professional programmer's day, and that's not something you learn in an advanced algorithms course in University.
You see the same distinctions in other trades as well; there are those who perform the trade and advance the state-of-the-art as far as actually doing the work goes, and there are those who do the underpinning research and advance the state-of-the-art as far as theory and fundamentals go.
Perhaps it would be helpful to distinguish the two verbally: there's computer science, and there's software development, two very different disciplines, both of which involve programming to some degree.
Donald Knuth is a computer scientist. Joel Spolsky is a software developer. :)
Greg 02/27/2007 11:39
I like writing frameworks, not in the sense that I like spending endless hours doing XML (I would never use XML for configuration, but I digress), but more in the sense that I like creating a base of code that makes it extremely easy to implement whatever else is needed for the system. The part of coding that involves making a spec come to life is kind of boring to me. I prefer all the early work making the system upon which the spec will be built.
Then again, I rewrite my framework every few years, so maybe I'm just a masochist.
Carl 02/27/2007 16:07
The point about programming needing a "creative energy" and "huge mental effort" are spot on. Yes it's not quite playing a piano, but in some ways it's more difficult. For me programming has always been about building "code models" of a problem and the sheer joy of having that model running elegantly.
all of this joy is lost in the vacuum of the "office".
I feel very elitist about this topic: way too many people are trying to be a "code artist" who just don't have the talent, passion or capability. I mean how can you ever have a production line for art ?
Robert Hook 02/27/2007 19:05
Thanks for writing that up Andrew. Like you, I've been watching this and related discussions progressing, as I hope that from it may evolve the first sensible steps toward turning programming from a black art to a profession. However, there is one point where I would beg to disagree:
"We don't want to write yet another web application framework"
One thing that is currently alarming, and distressing me, about the FOSS movement is that this is exactly what the best and brightest seem to be doing: endlessly generating new frameworks that are never quite complete, never quite useable, never quite finished. Somewhere along the way, I fear, a culture has arisen where that is seen as progress, and I am alarmed that the very clever coders who are doing that work genuinely may not understand that they are not solving the problems that need to be solved. When I look at projects like Axis (current bane of my existence) I see a pattern of behaviour and thinking that is of concern:
"The fence needs painting"
"Ok, we will need somewhere to store the paint"
"Um, yeah, ok, that could be handy"
"We'll build a shed"
"Will that get the fence painted?"
"It will make fence painting much faster and easier"
"Well, I guess so"
"And we'll let you paint the shed any colour you like"
Several years later, the shed has three walls and a partial roof, and you are allowed to paint the door any colour you like, have a choice of seventeen different latches and bolts for the door, and can install any style of window in the wall that is not yet finished. Oh, and the fence still isn't painted.
My point, reached after a vast digression, is that it seems the young fellas coming up behind us do like to spend lots of times building new frameworks.
Tapan 02/27/2007 22:31
Coding for me is something like a conglomeration of a scientist's intelligence, an artist's creativity, a philosopher's thinking and lot more. It includes all the facets of technical skills and management. You may not be interested in the feasibility requirement or the efficiency requirement of the system whose code you are writing, but you will definitely get thrilled to check how much memory my code is using and how faster it gives me the result. A person who gonna use your system wont ever care what's in the core but he will always get amazed. "How could it ever happen?" Man I luvit... And I am talking on behalf of a Computer Scientist and not as a Software Developer.
userd 02/28/2007 01:04
Answer to Skippy's questions:
Question 1. Can he possibly be a good programmer? Yes. But he needs to at least be willing to listen to someone who will do the other work (design, testing) for him.
Question 2. Would you like to have to use this framework? Not unless someone documents it.
Question 3. Would you like to maintain his framework? Maybe, but probably not. The word "maintain" makes my eyes glaze over.
Vinay 02/28/2007 01:07
Programming is process simmilar to playing a instrument , where in the programmer plays with the nodes and awaits eagerly for the results ...
brikhous 02/28/2007 18:50
As someone who utilizes MDA, I suggest you change your categorization of UML as an architect's tool since it is indeed a form of programming, just more abstract. Thank You.
Chuckls 03/03/2007 15:33
I equate coding to playing chess. Good programmers and good chess players are always trying to reach the end-game in the most efficient way. Chess players look at the pieces on the board and envision the moves and counter-moves needed to reach checkmate. Programmers view the requirements and resources available and envision the code relationships and interactions necessary to meet the requirements using the resources available.
Code is emphasized because programmers can more easily predict the effects of executing the code on the state of the computer/computer network. The computer/computer network equates to the chess board and code equates to moving chess pieces.
MDA and UML are more abstract than coding. A given UML diagram can represent many different coding implementations, both good and bad. Programmers prefer coding, they are implementers not modelers. Programmers do use models, implicitly or explicitly, but, programmers are more interested in finding an optimum implementation of a model than in the model itself.