Executive Summary: To program or not to program? A 20-year
veteran examines the profession from the inside out to determine if
it's worth the headaches.
There's an old country western song that starts with "Mothers
don't let your babies grow up to be cowboys." Change the word
cowboys to programmers and you've got a new hit on your hands. If
you think being a cowboy is tough, you should try programming.
Being a programmer is a lousy job. I've been one for 20 years, so
I know what I'm talking about.
First of all there's the "Spouse Effect." Did you ever notice
that if you ask what a programmer is working on you can't seem to
get away from him? He just keeps droning on and on about this
linked list he wrote or that bug he had to find but couldn't. Why
do we run on like that? Some people think it's because programmers
are boring. That's not the reason.
The reason is the Spouse Effect. When programmers go home
after work their wives (or husbands) don't ask what they did during
the day. Perhaps when they were newlyweds they used to ask, but
now they know better. I mean what are you going to say to your
spouse? "Dear, it was really exciting today. There was this bug
I was working on. It involved critical regions and multi-tasking
access controlled by semaphores. The problem seemed to have
deadlocking components - it was, like, a stochastic bug and I found
it!"
Her eyes would glaze over. If you've been married under a
year she might fake interest, but beyond that, forget it. The only
way programmers can get their wives to listen is if the wife's day
has been so filled with crying kids and diapers that she'd listen
to a grocery list as long as it was read by someone over three. As
a result, programmers have no one to share their professional life
experience with.
As proof of the Spouse Effect just ask yourself when was the
last time you saw a TV show titled "LA Software?" I can see it no,
"This week on LA Software, Richard Recursion tries to figure out a
functional requirements document before the deadline, while Sally
Stack finds that there's more than one way to finish her
documentation." Pretty exciting stuff, huh?
If programming's so boring you'd think it would be a pretty
low-pressure job, right? No way! Not only is the job lousy
because no one want to hear about it, the job is lousy because the
pressure makes you crazy. Everyone I know who programs for a
living is a manic depressive. They'll come bursting into your
office screaming, "I've found it! I've found it! It's that bug in
the Smackwacker project that I've been looking for for the last six
months." They're so thrilled (manic) that they've found the
problem. They just have to tell you about it (Spouse Effect). Two
hours after you happen by their office and you catch sight of the
same co-worker engaged in some serious head-banging. "What's up?"
you cheerfully volunteer.
"Oh God, my life's over," comes the reply in a tone
reminiscent of the '60s draft lottery. "There's another bug in the
Smackwacker - I just can't find it.
I call this the "Last Bug Roller coaster." You find that last
bug and you know in your heart of hearts that it's absolutely
positively the last one in the entire program. You'll never
(repeat, never) have to find another one as long as you live. Of
course, there's always another one so your joy at finding the "Last
Bug" is short-lived. One minute you're up and the next minute
you're down. Up and down, up and down...
And while we're on the subject, just think about bugs. Grace
Hopper ELP (Elderly Lady Programmer) takes credit for coming up
with the term "bug" back in the early 50s. Supposedly when her
electro-mechanical computer wouldn't work they discovered a fly
(the original bug) caught in one of the relay contacts.
If you believe that story I've got this bridge over the East
River I'd like to show you. We call them bugs because no human
being could stand calling them what they really are - stupid
mistakes!
"You know that stupid mistake I was working on last week?
Well, it turned out that the stupid mistake was a result of my
adding in one's complement arithmetic instead of two's complement
arithmetic. I just know that's the last stupid mistake I'll find
in the program."
In what other profession do the practitioners discuss their
mistakes with more gusto or pride? I can hear two heart surgeons
talking: "Well, you know that patient I had die on me last week?
I just couldn't figure it out, I though and thought - he just
wasn't responding to treatment. I finally opened him up again and
you know what? I'd left three sponges, two retractors, and a
surgical glove in him! I'll bet that's the last bug I'll find in
that transplant."
Programming's lousy work because of Charlie Chaplin, too. You
remember those old IBM ads they used to run? Some madison Avenue
clown figured out that Big Blue wasn't moving enough iron because
customers were afraid that programming was too hard. They were
afraid that automation was going to be beyond them. The response
to this fear is now the underlying theme in all software and
hardware ads: Simplicity. "Programming our computer is so simple
even a little tramp can do it." A typical commercial finds out
little tramp facing a hat factory gone berserk. In rolls the IBM
PC and with a keystroke here, a graphic there, and here and there
a spreadsheet, everything is running as smooth as silk.
Who believes those ads? Only people who haven't the faintest
idea how hard it is to develop systems. People who read the
Cliff's Notes versions of comic books. In short, your boss.
Ah, yes, your boss. A man (unless you work for HP) who is
interested in only one thing - getting it done on time. He doesn't
want to hear about your bugs. He just wants to know if you're on
schedule. Software schedules. I love 'em. Let me explain
software schedules through the use of cleverly simple metaphor.
Imagine for a moment that you solve crossword puzzles for a living.
You're a professional crossword puzzle solver. You went to college
to study crossword puzzle science. You've been solving them both
on and off the job for a few years now and you've got a few tricks
up your sleeve. You own a Franklin Spelling Ace and you think you
can hold your own against anyone.
Now your boss comes in and wants you to estimate how long it's
take you to knock off a few puzzles. Only you can't actually see
the puzzles, instead you get a brief description of the puzzles.
You scratch your head, ask a few deep probing questions like, "How
many words in each?" and then you tell your boss, "Gosh sir, I
really don't know how long it'll take."
"Come on, Flarity," comes the response, "I've got to five the
president some feeling for the magnitude of the job - just five me
an estimate."
There are the key words: "just an estimate." When your boss
says "just an estimate" you hear him saying "I won't hold you to
it," but he hears himself saying "give me precisely how long it
will take." After all, if he weren't going to do something with
the estimate, why did he ask for one?
You say, "Oh, gee, three weeks."
Now you're dead meat. The boss brings you the crossword
puzzles you've committed to solving in three weeks. Almost as bad
is correcting someone else's puzzles or eradicating bugs. But why,
you ask, couldn't just anyone fix the bugs? Couldn't someone just
"read the documentation" and fix the problem?
Being a support engineer, the first thing you discover is that
all software documentation is implemented as an "oral tradition."
Based on the tribal documentation techniques pioneered by the
American Indian, absolutely nothing of any importance is written
down. All information is passed down through the ages by telling
stories around the campfire.
Of course, modern programmers have improved the method. For
example, the campfire has been replaced by a conference room table,
and charcoal on bearskins has been replaced by magic markers on the
white formica stuff that can only be erased by the sleeve of you
new sports coat.
The basic technique is still the same. If you want to know
how anything works, you must find the person who wrote the module
and ask him. Twelve years ago I worked for Bell Labs.
Occasionally I'll run into the current engineer of my old project
at the mall. "Hi, Tim," he'll say. I smile a weak smile knowing
full well what will follow.
"How are the wife and kids?" he'll ask. We'll chat briefly
about the weather or the Knicks and then he'll turn to leave but
stop short as if remembering something. "Hey, can I ask you about
that Smackwacker module? When you set bit 15 on did that mean go
left or go right?"
Programming - It's a lousy job. So why do we do it? I don't
know, maybe it's the hacker in us. Maybe it's a chemical that they
put in those orange-colored peanut butter cheese crackers. Or
maybe it's when that one misguided user calls you up to say, "You
know, that Smackwacker system is really not bad, not bad at all."
There is a certain perverse pleasure in the craft. True,
wives don't want to hear about it, the brain-bruising pressure can
drive you nuts and the boss just doesn't understand, but still...
there's something about programming that makes all the other jobs
seem just a little but worse.
(Note: Tim Chase is a Founder of Corporate Computer Systems in New Jersey)