THE VETERAN NEOPHYTE

The Downside

DAVE JOHNSON

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

• 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 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.*