According to the menu bar clock on my computer screen, it was 1:38A. M. My eyes
were raw and stinging, my neck was stiff, and my mind was jittery and frazzled. I had
to get some sleep soon, because the alarm clock, glowing weakly red in the dark in the
next room, right there next to my soundly sleeping wife and animals, was set to go off
at 5:30. I'd been ready to stop two hours ago, having lost yet another entire evening to
the computer, but I found that there was some obscure system structure that wasn't
being disposed of when my program quit, even though I never directly created or used
that structure in my code. Dang. I hate that.
The program I was writing is a kind of "magic graph paper" that can help me figure out
multiperson juggling patterns. It was originally intended to be the topic of this
column, but it took a lot longer to write than I thought it would, and it still isn't done;
it will have to wait for some future column. So there I was, deadline approaching,
without a topic. I was whining about my foiled plans to my friend Ned (a tolerant
listener), complaining loudly about the amount of time and trouble it takes to write
the simplest piece of code, bitching and moaning about the trials and tribulations of
programming, and wondering out loud what I was going to write about.
Then it dawned on me -- write about the downside! Write about the parts of
programming that frustrate you so much! Get those nasty feelings out on paper! Purge!
Catharse! I could even do another little electronic survey, sort of the opposite of the
"Why We Do It" column in Issue 17. Hot dawg.
So that's what this column is about: "What do people hate about programming?" I
posted this question to various news groups on the Internet, and sent it out via e-mail
to a bunch of programmers I know, and got some good responses. But before I tell you
what other people hate about programming, first it'smy turn, and I'm ready to gripe.
Once upon a time, I loved programming. It was ahobby, something I did for the sheer
joy of it, somethingthat wasfun . I welcomed the chance to learn all the arcane and
grungy details of the internal workings of the computer. I binged, ignoring the demands
of my home life and my body. I dove willingly into the thick, impenetrable books,
joyfully grappling with myriad problems that had nothing whatever to do with the
program I was writing. The program itself was in many ways incidental: it was that
continual solving of difficult problems that was both the fuel and the reward, the stick
and the carrot combined.
Well, I still go on binges now and then, small ones, but it's much rarer. Before, I
would pursue just about any harebrained idea that crossed my feverish mind (and
abandon most of them later, half constructed, often after I'd enthusiastically
programmed myself into a corner). Nowadays I abandon most ideas much sooner,
usually long before I even hit the keyboard. Now, every time I think of a fun
programming project (which still happens often), I immediately quail at the thought
of sitting down and beginning. Knowing up front how much time and effort is required
to accomplish even the simplest things just makes me want to go to sleep. Call me a
burnout, call me a wimp, call it growing older, or call it growing up: you'll be right on
every count.
But why? What changed? It used to be so different. It used to be that I would dive in
immediately at the first glimmer of an idea, hacking and slashing my way through the
Toolbox with gleeful abandon, forgetting to eat, forgetting to sleep, forgetting to check
errors, sitting in the same position for hours on end, staring, typing, staring, typing,
staring . . .
Wait a second. That's something that bugs me about programming. Even though the
action in my head is fast, furious, and fascinating, physically I just sit, stare, and
type. Maybe someday I'll get enough RAM in my Duo to actually do some coding
outdoors, but I'llstill be sitting, staring, and typing; I'll just have a better view on
the rare occasions I remember to look up from my lap. (Come to think of it, it might
be even worse, since I'll be forced to use electronic references as well: I won't even get
the small breaks that I normally get while flipping pages in some weighty tome of
wisdom.) So even though programming is fundamentally acreative thing, teeming with
meaning and craftsmanshipand beautiful logic, there's a tradeoff. To partake of that
sweet creation, you have to be willing to mostly sit still, stare at glowing humming
boxes that make your face look green, and type cryptic symbols in a very strict,
"filling out forms" kind of way. For hours. And hours. Andhours . I can almost feel my
muscles turning to liquid, my blood slowing and thickening, gravity slowly pulling my
withered flesh from my bones.
That's something else annoying about programming, and about computers in general:
the amount of time they require. They are infinite time sinks, no doubt about it. Maybe
time is just more precious to me now than it was before, and I'm less and less willing
to spend it sitting at a computer. Writing software, in particular,always takes too
long. It takes much longer than it reasonably ought to, and it takes much longer than
you think it possibly can. Every time. There's a common rule of thumb for estimating
how long it will take to complete a software project: come up with a reasonable
estimate of the time required; then double it. Amazingly, even that doesn't do it. I've
heard another, more tongue-in-cheek formula that says to take your best estimate,
double it, and then jump to the next larger time unit. For example, if you think a
project will take 8 weeks, first double it to 16 weeks, then change the time unit from
weeks to months: 16 months is reasonable. Nowthat might actually be accurate.
(I remember some time ago there was a seminar here at Apple given by someone who
had a system that was carefully worked out to produce accurate estimates of software
projects. The system was entirely history based; that is, the estimates weren't based
on the details of the project or the estimates of the engineers involved or the
marketing plans for the product, but instead were based on how long it had taken to
complete past, similar projects. It sounded very promising to me, but you know what?
The estimates thus produced were so much longer than those arrived at by conventional
means that real adoption of that sort of system would require a fundamental change in
the way the software business is run. I haven't heard about it since.)
Part of the reason programming takes so long, of course, is that much of the time is
spent on tasks that really have nothing to do with the program you're trying to write,
but instead are about bookkeeping, working around the limitations of the machine,
trying to figure out how to express your very clear ideas in the hobbled, awkward
prose of "modern" computer languages, and so on. That's another thing I hate about
programming: the mountains of mind-numbing and irrelevant detail you have to wade
through and deal with to accomplish the simplest tasks. I don't really give a hoot about
the details of the operation of the file system, I just want to get some information onto
the disk; I don't really want to know how scroll bars work, I just want the user to be
able to navigate an area larger than the window. This is, naturally, a good argument for
using frameworks (among many other good arguments), but the promise is still
beyond the reality, and even with a good framework there are still mountains of
irrelevant detail. They're different mountains, and they might be a little smaller, but
they're still mountains, and they're still irrelevant.
Another thing: software is never really done, just shipped. That's another aspect of the
"infinite time sink" thing. There's always something more that can be done to make a
program better, and there are always bugs that can be fixed. I've heard some artists
and writers say that they never actually finish a piece, they just stop working on it
(and, incidentally, that knowing when to stop is where a lot of the art is). Software is
often the same way.
Programming is also addictive, and I hate that, too. (I'm starting to feel like Andy
Rooney here.) It positively consumes me. There I'll be in the umpteenth hour, my eyes
burning, my head aching, my neck stiff, everyone else fast asleep, warm and cozy in
their nice, soft, analog beds. But I can't stop, because there's just one more little
wrinkle to iron out, one more small problem to solve. And the solution to that problem
leads to another problem, and the solution to that one leads to another, and . . .
Know what else I hate? Bugs. Not the plain old easy to find kind of bugs, but the nasty,
subtle, elusive, intermittent kind that just don't seem to have a deterministic cause.
They're an unavoidable part of programming, but I hate 'em anyway. (Seymour
Papert, in his bookMindstorms, made the excellent point that programming is one of
the few disciplines where you're expected to make mistakes, every time, and an
integral part of the process is going back over your work, finding the inevitable
mistakes, and fixing them. This is in sharp and healthy contrast to most academic
subjects, where mistakes are thought of as unwelcome anomalies rather than an
inevitable part of the process. An excellent reason, says Papert, to teach programming
to children: it introduces them to the fact that mistakes are an integral part of
real-world processes.) Knowing that there reallyis a solution to the bug (and
probably an easy one) just pisses me off even more. If there's an answer, why can't I
find it? And after spending days and nights sleuthing my way to an eventual answer, do
I rejoice when I arrive? No, I'm just angry that I had to waste so much time on
something that didn't really move me further forward. Hope starts to fade; ennui
begins its inexorable descent.
And finally, well, programminghurts. It hurts my body, and it also hurts my brain.
It's unnatural to think like that, composing long strings of imperatives, with no
subtlety or nuance or fuzziness of meaning allowed, especially for long, uninterrupted
periods of time. It's somehow dehumanizing, because to program well you have to
assume the characteristics of the machine, you have to think like one, you have to
make your thoughts linear and ordered. It's just not normal.
All right, that's probably enough personal griping. Ido feel a little better having gotten
that off my chest, here in public. Now let's see what other people had to say.
In general I was surprised at the paucity of responses, at least compared to the
veritable flood of replies I got when I asked what peopleliked about programming. Of
course, I was asking programmers, and since they do it for a living they presumably
don't hate it too much.
Of the responses I got, the most commonly hated thing by far was bad or broken tools.
This wasn't surprising; programmerslove to complain about their tools. In particular,
buggy compilers were soundly thrashed from all sides as the worst time wasters
around. Dealing with your own bugs is one thing; that's a normal part of the
programming process. Dealing with bugs in your tools, though, and having to work
around them, is something else entirely:
I LIKE programming. The only things that bother me are things that are not under my
control, like compiler bugs. I hate that. -- Matt DiMeo
After a while, the tools got to me. Tools with bugs and bad interfaces made the
day-to-day work more like digging a ditch than the artistic expression it maybe could
be. I don't like to dig ditches, I like it to be interesting. -- Bo3b Johnson,
semiretired programmer (the "3" is silent)
This is one of the things that came up over and over: the primitive state of the tools
available. Programmers in particular, since they know intimately what the machine
is capable of, are appalled at the state of the tools available for programming. Memory
management was cited often as a needless hassle -- many C and C++ programmers
actually mentioned dynamic languages in a positive light,mostly because of the
automatic memory management and the banishing of the compile-link-debug cycle.
Lots of folks also complained about the job of programming, and most of those
complaints fell into the realm of "the nonprogrammers just don't get it."
The interactions with the management. You know, these silly men with ties that say,
"Well, you should change that program to act THIS way, and not in the way we agreed
last week," when you have the job half done. -- Maurizio Loreti
Maybe that's why geeks seem to congregate in groups: only other geeks really get it.
Interestingly (from my Macintosh perspective), a number of people mentioned
interface programming as something they hated:
I have a special hate mode for doing GUI programming. It's boring, it's arcane, and it's
ill behaved. Give me systems, give me new real terrain to learn and think about, but
leave the GUI programming to robots! -- Jeffrey Greenberg
This surprised me a little, I must admit, partly because I reallylike that part of
programming. Almost all of my little toy projects involve lots of clicking and dragging
of widgets on the screen, and now that I think of it, programming didn't really begin to
interest me until I discovered the Macintosh and user interaction. But hey, everyone's
entitled to an opinion.
Another frequently mentioned offender was lousy APIs:
Number two: Poorly designed OS and peripheral interfaces, where I have to keep track
of a lot of "moving parts" to do something that should be straightforward. -- Tom
Breton
That's another example of something that seems pervasive: complaints about the
software layers that surround most programs these days. It's pretty much unavoidable
now; you can't write a program without depending heavily on the software
environment you're programming for. Your software is controlled from the outside by
other software (typically a GUI these days), and in turn your software isn't directly
controlling the machine like in the good old days, but is instead callingother pieces of
software (like the Toolbox or a framework) to accomplish its tasks. So naturally it's
annoying when the software you depend on is badly designed or buggy. Unfortunately,
it's all too common an occurrence.
A few also mentioned a lack of programming quality or a lack of professionalism as a
big downside:
I get really livid when I find a reckless patch or hack in products, specifically those
that make a nightmare for future development and integration. They demonstrate a
selfish and irresponsible form of engineering. -- Dave Evans
Unfortunately, most of the programmers I've been around are immature and not well
managed, so you end up with these massive schedule and quality problems. I claim it's
immaturity, because if we are still stuck in low gear trying to impress our friends
with our tricky code, that's high school behavior. That's mostly what I saw. "Ooh, I can
save 12 bytes if I write this in a stupid way. Aren't I clever?" Too bad no one can read
it. Or, "Ooh, I can make this faster if I write it obscurely. I'm so cool." Never mind
that it never gets used. That sort of lack of professionalism is what put me over the
edge. -- Bo3b Johnson
Finally, and near and dear to my heart, is the issue of being forced to interact with the
machine: I hate the actual typing in of all the stuff. After a pleasant period of roaming
around, scribbling down nice little try-outs and possible solutions, just using old
pieces of paper, lying down on the couch, thinking a bit, reading a bit, talking things
over with a couple of colleagues, there comes a long, boring period when I'm almost
chained to that silly desk, sitting in front of that silly machine, banging that silly
keyboard, trying to express my illuminated thoughts in some sort of silly
programming language . . . I want my couch, I want my can of beer, I want my
cigarettes and my books; THAT'S how I want to program. -- Jos Horsmeier
. . . spending the greater part of my life at a !#@!$* keyboard, staring at a !$&*!#
monitor. -- Anonymous
Yep, that's the part that I hate the most, too; in order to program I have to spend huge
amounts of my time sitting at the computer. You know, digging ditches is starting to
sound better and better. It's tactile, it's immediate, it's outdoors, it uses muscles
beyond those in your forearms, it doesn't consume or pollute your mind, there's no
irrelevant detail to deal with, and when you're done you're done. Though I could be
wrong, I don'tthink ditch digging is addictive, and I'm quite sure that there's no
possibility of subtle and elusive bugs. Sounds good.
Hey, that gives me an idea! With QuickDraw GX's great hit testing and picture
hierarchies, I could write a really cool ditch-digging simulator . . .
RECOMMENDED READING
DAVE JOHNSON has an inordinate (some say irrational) love of playground swings.
He's been a lover of swings and swinging as long as he can remember, and still does
backflips out of them from maximum height, impressing mightily any kids who might
be watching. He's also been known to suddenly stop the car and leap out at the sight of a
swing set he hasn't visited before. No swing shall be left unswung.*
Thanks to Jeff Barbose, Brian Hamlin, Bo3b Johnson, Lisa Jongewaard, and Ned van
Alstyne for their always enlightening review comments.*
Dave welcomes feedback on his musings. He can be reached at JOHNSON.DK on
AppleLink, dkj@apple.com on the Internet, or 75300,715 on CompuServe.*