Reflections on Programming

Source

From "Out of Time: Reflections on the Programming Life," by Ellen Ullman, a chapter in Resisting the Virtual Life, edited by James Brook and Iain A. Boal. Ullman is a software engineer living in San Francisco.

Getting close to the machine

People imagine that computer programming is logical, a process like fixing
a clock. Nothing could be further from the truth. Programming is more like
an illness, a fever, an obsession. It's like riding a train and never being
able to get off.
        The problem with programming is not that the computer is illogical
- the computer is terribly logical, relentlessly literal. It demands that
the programmer explain the world on its terms; that is, as an algorithm
that must be written down in order, in a specific syntax, in a strange
language that is only partially readable by regular human beings. To
program is to translate between the chaos of human life and the rational,
line-by-line world of computer language.
        When you program, reality presents itself as thousands of details,
millions of bits of knowledge. This knowledge comes at you from one
perspective and then another, then comes random thought, then you remember
something else important, then you reconsider that idea with a what-if
attached. For example, try to think of everything you know about something
as simple as an invoice. Now try to tell an idiot how to prepare one.
That's programming.
        I used to have dreams in which I was overhearing conversations I
had to program. Once I dramed I had to program two people making love. In
my dream they sweated and tumbled while I sat looking for the algorithm.
The couple went from gentle caresses to ever-deepening passion, and I treid
desperately to find a way to express the act of love in the C computer
language.
        When you are programming, you must not let your mind wander. As the
human-world knowledge tumbles about in you head, you must keep typing,
typing. You must not be interrupted. Any break in your concentration causes
you to lose a line here or there. Some bit comes, then - oh no, it's
leaving, please come back. But it may not come back. You may lose it. You
will create a bug and there's nothing you can do about it.
        People imagine that programmers don't like to talk because they
prefer machines to people. This is not completely true. Programmers don't
talk because they must not be interrupted.
        This need to be uninterrupted leads to a life that is strangely
asynchronous to the one lived by other human beings. It's better to send
e-mail to a programmer than to call. It's better to leave a note on the
chair than to expect the programmer to come to a meeting. This is because
the programmer must work in mind time while the phone rings and the
meetings happen in real time. It's not just ego that prevents programmers
from working in groups - it's the synchronicity problem. Synchronizing with
other people (or their representations in telephones, buzzers and
doorbells) can only mean interrupting the thought train. Interruptions mean
bugs. You must not get off the train.

I once had a job in which I didn't talk to anyone for two years. Here was
the arrangement: I was the first engineer to be hired by a start-up
software company. In exchange for large quantities of stock that might be
worth something someday, I was supposed to give up my life.
        I sat in a large room with two other engineers and three
workstations. The fans in the machines whirred, the keys on the keyboard
clicked. Occasionally one of us would grunt or mutter. otherwise we did not
speak. Now and then I would have an outburst in which I pounded the
keyboard with my fists, settting off a barrage of beeps. My colleagues
might have looked up, but they never said anything.
        Real time was no longer compelling to me. Days, weeks, months, and
years came and went  without much change in my surroundings. Surely I was
aging. My hair must have grown, I must have cut it, it must have slowly
become grayer. Gravity must have been wrking on my late-thirties body, but
I didn't pay attention.
        What was compelling was the software. I was making something out of
nothing, I thought, and I admit that the software had more life for me
during those years than a brief love affair, my friends, my cat, my house,
or my neighbor who was stabbed and nearly killed by her husband. One day I
sat in a room by myself, surrounded by computer monitors. I remeber looking
at the screens and saying, "Speak to me."
        I was creating something called a device independent interface
library. ("Creating" - that is the word we used, each of us a genius in the
attic.) I completed the library in two years and left the company. Five
years later, the company's stock went public, and the original arrangement
was made good: the engineers who stayed - the ones who had given seven
years of their lives to the machine - became very, very wealthy.

If you want money and prestige, you need to write code that only machines
or other programmers understand. Such code is called "low." In regular
life, "low" usually signifies something bad. In programming, "low" is good.
Low means that you are close to the machine.
        If the code creates programs that do useful work for regular human
beings, it is called "high." Higher-level programs are called
"applications." Applications are things that people use. Although it would
seem that usefulness is a good thing, direct people-use is bad from a
programmer's point of view. If regular people, called "users," can
understand the task accomplished by your program, you will be paid less and
held in lower esteem.
        A real programmer wants to stay close to the machine. The machine
means midnight dinners of Diet Coke. It means unwashed clothes and bare
feet on the desk. It means anxious rides through mind time that have
nothing to do with the clock. To work on things used only by machines or
other programmers - that's the key. Programmers and machines don't care how
you live. You can stay, come, go, sleep - or not. At the end of the project
looms a deadline, the terrible place where you must get off the train. But
in between, for years at a stretch, you are free: free from the obligations
of time.

I once designed a graphical user interface with a man who wouldn't speak to
me. My boss hired him without letting anyone else sit on the interview. My
boss lived to regret it.
        I was asked to brief my new colleague with the help of the third
member of our team. We went into a conference room, where my co-worker and
I filled two white boards with lines, boxes, circles, and arrows while the
new hire watched. After about a half hour, I noticed that he had become
very agitated.
        "Are we going too fast?" I asked him.
        "Too much for the first day?" asked my colleague.
        "No," said our new man, "I just can't do it like this."
        "Do what?" I asked. "Like what?"
        His hands were deep in his pockets. he gestured with his elbows.
"Like this," he said.
        "You mean design?" I asked.
        "You mean in a meeting?" asked my colleague.
        No answer from the new guy. A shrug. Another elbow motion.
        Something terrible was beginning to occur to me. "You mean
talking?" I asked.
        "Yeah, talking," he said. "I can't do it by talking."
        By this time in my career, I had met many strange software
engineers. But here was the first one who wouldn't talk at all. We had a
lot of design work to do. No talking was certainly going to make things
difficult.
        "So how *can* you do it?" I asked.
        "Mail," he said. "Send me e-mail."
        Given no choice, we designed a graphical user interface by e-mail.
Corporations across North America and Europe are still using a system
designed by three people in the same office who communicated via computer,
one of whom barely spoke at all.

Pretty graphical interafaces are commonly called "user-friendly." But they
are not really your friends. Underlying every user-friendly interface is
terrific contempt for the humans who will use it.
        The basic idea of a graphical interface is that it will not allow
anything alarming to happen. You can pound on the mouse button, your cat
can run across it, your baby can punch it, but the system should not crash.
        To build a crash-proof system, the designer must be able to imagine
- and disallow - the dumbest action possible. He or she has to think of
every single stupid thing a human being could do. Gradually, over months
and years, the designer's mind creates a construct of the user as an
imbecile. This image is necessary. No crash-proof system can be built
unless it is made for an idiot.
        The designer's contempt for your intellignece is mostly hidden deep
in the code. But now and then the disdain surfaces. Here's a small example:
You're trying to do something simple such as copying files onto a diskette
on your Mac. The program proceeds for a while, then encounters an error.
Your disk is defective, says a message, and below the message is a single
button. You absolutely must click this button. If you don't click it, the
program will hang there indefinitley. Your disk is defective, your files
may be bollixed up, but the designer leaves you only one possible reply.
You must say "OK."
        The prettier the user interface, and the fewer replies the system
allows you to make, the dumber you once appeared in the mind of the
designer. Soon, everywhere we look, we will see pretty, idiot-proof
interfaces designed to make us say, "OK." Telephones, televisions, sales
kiosks will all be wired for "interactive," on-demand services. What power
- demand! See a movie, order seats to a basketball game, make hotel
reservations, send a card to mother - all of these services will be waiting
for us on our televisions or computers whenever we want them, midnight,
dawn, or day. Sleep or order a pizza: it no longer matters exactly what we
do when. We don't need to involve anyone else in the satisfaction of our
needs. We don't even have to talk. We get our services when we want them,
free from the obligations of regularly scheduled time. We can all live,
like programmers, close to the machine. "Interactivity" is misnamed. it
should be called "asynchrony": the engineering culture come to everyday
life.
        The very word "interactivity" implies something good and wonderful.
Surely a response, a reply, an answer is a positive thing. Surely it
signifies an advance over something else, something bad, something that
doesn't respond. There is only one problem: what we will be interacting
with is a machine. We will be "talking" to programs that are beginning to
look surpisingly alike; each has little animated pictures we are suppposed
to choose from, like push buttons on a toddler's toy. The toy is meant to
please us. Somehow it is supposed to replace the rewards of fumbling for
meaning with a mature human being, in the confusion of a natural language,
together, in a room, within touching distance.
        As the computer's pretty, helpful face (and contemptuous underlying
code) penetrates deeper into daily life, the cult of the engineer comes
with it. The engineer's assumptions and presumptions are in the code.
That's the purpose of the program, afterall: to sum up the intelligence and
intentions of all the engineers who worked on the system over time - tens
and hundreds of people who have learned an odd and highly specific way of
doing things. The system reproduces and re-enacts life as engineers know
it: alone, out of time, disdainful of anyone far from the machine.