Site Presented By
Monday, Oct 6, 2008
"The Bug" author Ellen Ullman talks about the Gothic terrors that lurk between the rational lines of computer code.
May 16, 2003 | When C.P. Snow first identified the rift between "two cultures" of scientists and literary intellectuals who could neither understand nor communicate with each other, it was 1959, and computing was in its infancy. Today, in many fields, the denizens of Snow's two cultures are reaching across the gap. But computer programming remains a vast unknown country to most outsiders -- even as more and more of our work and our culture stands on its foundation.
Ellen Ullman has lived in that country, and ever since the 1997 publication of her memoir, "Close to the Machine: Technophilia and Its Discontents," she has meticulously and articulately chronicled its customs and dangers. An English major turned programmer turned writer, she has a knack for talking about the experience of writing code -- "thought that works," as one of her characters puts it -- in ways that nonprogrammers can understand. She does so without glorifying the creators of software, as scribes of the Internet boom would; but she doesn't trivialize their work or their lives, either. She does full justice to the highs and lows of the programming life -- as both an unnatural punishment for the human organism and an invigorating challenge to the human brain.
"The Bug," Ullman's new novel, tells the tale of Ethan Levin, a programmer bedeviled by an elusive, infuriating bug that resists every attempt to corner it. As the hunt for this software nemesis grows fiercer, Levin's personal life unravels.
I talked with Ullman at her writing studio in a 1912 office building, just south of Market Street in San Francisco.
"The Bug" started as nonfiction. How did it evolve into a novel?
After I finished "Close to the Machine," I thought, well, what now? The most direct route for me seemed to be to collect some essays I'd already published. To complete that, I thought I'd write a novella-length essay about a bug I'd had when I was a programmer in the mid-'80s -- a bug that drove me crazy. It came and went. I could not figure out what was causing it. No one could reproduce the set of circumstances that actually led to it.
In "The Bug," the programmer, Ethan Levin, scribbles down the evocative phrase, "Cannot reproduce."
If you can't reproduce a bug, the suspicion is it isn't there. That's one of the programmer's defenses: I can't reproduce this, so what are you talking about? But it was clear there was a bug. Out of the blue, the whole front end would just die. It was clearly my code, and I could not figure out what the cause of it was. And it really caused me despair. The rest of my work was going well enough. I was on schedule.
This was when you worked at Sybase?
Yes. I think I was the only engineer in the company on schedule, according to my boss. And so on the face of it things were not going badly. But it gnawed at me, because I knew it was lying in wait in there. There was something wrong at the heart of this system.
So I thought, that might make an interesting essay, a way for people who don't write software to understand the debugging process. To see how writing software is more or less equivalent to debugging. You have an idea of what you have to do, and you write some code, and then you have to get it past the compiler, and the compiler simply certifies that it's syntactically correct. But is the program doing what it's supposed to do? On the first pass, almost never. It's a reiterative process. You don't expect that you'll write your code, run it through the compiler, and everything will work.
People do write smaller, more object-oriented code now, and it's easier to write a small chunk of code -- but then it's harder to test how it will be when it all gets together. So there's really no escaping the debugging process.
I think the history of software engineering is trying to find a way to write reliable code and miserably failing, year after year. It wouldn't be a perennial topic in software engineering if anyone had any idea how to fix the problem of bugs.
But when I sat down to write, I really didn't get anywhere. It seemed too relentlessly techy. Then, when I tried to personalize it, I found I didn't want to write about my own life at that juncture. I didn't think it was that interesting. I'd already written a memoir. I thought, how much more of me do people really need?
So I thought, OK, I'll see if I can turn it into fiction. And that was a difficult decision, because I learned that fiction and essays really have very little in common. The impulse of an essay is to explain, somehow, even if it's only to yourself; but the impulse of fiction is to dramatize. I really had no idea how to write a novel.
Had you written fiction before?
I had. Lots of competently ordinary short stories that I'd sent away -- this was while I was programming, in the mid-'80s. I'd get nice rejections or form-letter rejections. I stopped doing that because I knew they weren't particularly good. I do have a novel in the drawer -- very bad, very long, 760-some-page manuscript. Three or four people have read it, to their detriment.
Was it about programming?
No, no, no, no, no. I thought of writing as a way to get away from programming. Programming to me was a job. It wasn't a mission. It didn't occur to me at that point, in the mid-'80s, to write about computer programming, which at that point was not a social and public phenomenon. It was what we used to call a back-room operation. It literally was back there with the general ledgers. At that point the world was not exactly waiting with bated breath, "Oh, what's going on in the back room with the computer?"
Get Salon in your mailbox!
