March 95 - THE VETERAN NEOPHYTE
THE VETERAN NEOPHYTE
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
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
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
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
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
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 . . .
- Snow Crash by Neal Stephenson (Bantam Books, 1992).
- Chicken Soup, Boots by Maira Kalman (Viking, 1993).
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
Dave welcomes feedback on his musings. He can be reached at JOHNSON.DK on AppleLink, firstname.lastname@example.org on the
Internet, or 75300,715 on CompuServe.*