acm - an acm publication
Articles

What's bugging Ellen Ullman?

Ubiquity, Volume 2003 Issue May, May 1 - May 31, 2003 | BY Ubiquity staff 

|

Full citation in the ACM Digital Library

A conversation with the author of "Close to the Machine," and "The Bug: A Novel".


A conversation with the author of "Close to the Machine," and "The Bug: A Novel".


Ellen Ullman worked as a computer programmer for more than 20 years, entering the field when few women were part of the computing culture. She is the author of the cult classic memoir Close to the Machine and currently writes for Harper's, Wired, and Salon; she has also been a regular guest commentator on NPR. She lives in San Francisco.

UBIQUITY: You are two persons: Ellen Ullman the programmer and Ellen Ullman the writer. Let's start with Ullman the programmer. How did you become a programmer in the first place?

ULLMAN: I never started out to become a programmer. I was first attracted to computing in the late seventies, but not as a profession. I'm really not exactly sure how it started. I began reading up on Trash 80s, the TRS-80s. I was going to buy one, because I had been a media person in my last years at college -- I did video and photography -- and I was attracted to hardware in general. And this, the computer, was just like another interesting kind of thing to get involved in. And I had learned something about programming back in college.

UBIQUITY: Where did you go to college?

ULLMAN: Cornell.

UBIQUITY: In a media program?

ULLMAN: No, I majored in English. But during my last two years there I was involved with a local media group that got funding from New York State Council on the Arts to do community-access video (this is the early days of cable, "community antenna TV" as it was called, or CATV). We went around town shooting videotapes, and gave local showings. Video was kind of a community organizing tool in those days, because you didn't have to spend millions of dollars to do it. Then when home computers came out, I was attracted to them in the same way I was attracted to the first portable videotape recorders: as affordable hardware you could use to make something interesting.

So I didn't really think about computers as a profession; I just thought about them as another interest in media. I was doing some electronic image-generation for video -- I remember aiming a camera at an oscilloscope that had this hand-made board attached to it. I would just connect various electronic components with alligator clips and see what happened. Anyway, around this time I saw my first computer-aided animation. I was immediately curious about it and thought, jeez, someday I'd like to do that. And so all of this was in the back of my mind later when I had to look for a job, and I thought, I'll just see if I can get a job programming. And so I did.

It was relatively easy to get a job as a programmer then, in the late '70s, early '80s, because business computing was exploding and there were very few people formally trained to do it. I mean, the computer science major barely existed. Here at Berkeley, I think it was a sub-department within electrical engineering, and people who studied to be electrical engineers weren't exactly going out there to work on general ledgers and invoicing. As a result, anyone who had touched a computer or had written a few lines of code or knew what a compiler was could get a job, and so I did.

UBIQUITY: So it was more or less an accident. "Just a job."

ULLMAN: Yes, I really saw it at the time as just a temporary way to earn some money to support my interest in photography and other artistic pursuits, but it turned into a 20-year profession without my ever expecting it. It became instantly engaging, and it just grabbed me. I mean, I even stopped taking pictures. In programming I found a possibility for engaged creativity that I had never expected would be there. And that was the beginning of it, and really I didn't stop until, like most programmers, I got tired of coding, something like 20 years later. I only know a few people who, after 20 years, still write code.

UBIQUITY: No more code for you?

ULLMAN: Now I think about code, I read some code, I follow technical developments -- but I no longer am a day-to-day programmer.

UBIQUITY: What languages do you feel most comfortable with?

ULLMAN: Well, I guess my home language is C. I can program in C++ and Java, but I don't like them. It's like learning foreign languages: some of them come to you very easily and some of them don't. I think C++ always felt ugly to me, because it's a language that never could decide whether it was a high- or a low-level language. I just don't find it very elegant. One of my former bosses calls it "the Winchester mystery house," because of all the under-the-code magic going on. I'd never feel at home in it, whereas I used to be able to debug C on the phone. Someone would call me up and read me some code and I'd just solve the problem for them. That's only possible when you speak a language fluently. I don't think I'll ever have that kind of fluency in C++.

UBIQUITY: When did you decide that programming really was a profession for you?

ULLMAN: I'd say it was really a product of just a few months. My initial job was as a technical support person -- in most companies technical support is considered the bottom, an entry-level job. And yet in those days, I could dial directly into a client's computer and edit their data! And there I was at the bottom of the food chain! I'm astounded people let me do that -- think of the damage I might have done. But it was a great way for me to learn on the ground, and within a few months, I'd been promoted, eventually to senior programmer.

I was very fortunate. I worked for a small software company, and the application was interesting. Part it involved electronic communications between companies, what today we'd call B2B software, business-to-business, though of course without the Web, just on dial-ups. It was implemented on a PICK operating system, which was a brilliant early system that included a relational database with an SQL-like query language, giving you all the tools to write good and robust applications. I was engaged instantly, especially with the architecture of the database.

Of course in those days code was very challenging because an entire program on a PICK system could not be larger than 32K -- you had to do overlays, subroutines essentially. Some of these programs had to do quite a lot, in addition to having an interactive user interface, so it was very challenging to write good, robust code. You had to create a good experience for the user and fit it all in 32K. You really had to learn your stuff in an environment like that. This helped me later, when I got into the engineering side, when I became a software engineer. My first job forced me to look under the covers.

UBIQUITY: Who were your programmer colleagues in those days?

ULLMAN: I don't think any of them had computer science degrees in the first several years. My immediate boss had two masters, one in sociology and the other in psychology, and the head technical guy, as far as I can tell, was a college dropout. He was another one of those brilliant college dropout types. The people around me, let's see, one woman had a degree in art history. In later jobs, people had degrees in library science, or Ph.D.'s in anthropology, or were all-but-dissertation in classics and such. These were very smart people, but none of them had had much formal training in computers. Still later, there was a next crop of people who came out of computer science programs, and I frankly found them much less interesting to work with. They knew a great deal about computers, but to me they seemed sort of shallowly educated -- or they weren't interested in much else besides computers -- and I think that hampered what they could do with the machine.

UBIQUITY: What are your thoughts about that? How would you advise people setting up a computer-science program to avoid this "shallowly educated" problem?

ULLMAN: First of all, I think the main thing about computers is that some things don't change at all, and some things change very rapidly. What changes very rapidly is the top layer, the implementation details, and that's going to keep changing, so there's no sense teaching that. I would simply teach people how to change languages and change operating systems, because what you need to do is keep educating yourself. You need to teach people how to keep teaching themselves, because the operational environment is never going to sit still.

On the other hand, the deeper questions of computing are perennial, and, at heart, operating systems have not really changed. For example, what's considered new these days is Linux, but Linux is based on Unix, so we're talking here, late '60s, early '70s design. There are deeper problems that never go away, that never get solved completely: how do you do multi-processing, how do you trade off between code compactness and the ability to maintain the code? Or tradeoffs between distributed or centralized computing. These things swing back and forth, back and forth.

For instance, on the question of distributed vs. centralized. When I first started, everything was centralized on the mainframe and there was something called timesharing, using dumb terminals or terminals with minimal local intelligence hanging off a central computer. Then we went completely the other way to a distributed model, with individual computers having their own processing power connected over a network, maybe sharing a data server. And now we've swung almost all the way back the other way, with everything on the server. [What's on the desktop, the client side, is a very abbreviated, rather stupid system. I mean, a browser is a rather primitive piece of code compared to the kind of client-side applications that you can develop when you're using the full resources of the desktop.] And I'm sure this will swing back again.

In a deeper sense, engineering is not about finding the solution but about making tradeoffs to find the current best use of resources. You balance one scarce resource against another to arrive at something workable for now -- with the understanding that as the environment changes, the solution will have to change. There isn't a right answer. There's only the current, best solution.

So I think if you could somehow teach students to understand that Linux or Windows or Java or C++ are just current implementations of old ideas, and to understand that what's new has roots in long-standing ideas that have gone through permutations. Computing is not a brand-new profession. It's a generation or two old by now. It has a history. I really would have people understand the history of computing much better. I mean a detailed survey of the different operating environments as they came and went over time, what they were good at, and what they were not good at. These ideas are getting lost.

UBIQUITY: Would you want computer science students exposed to any particular area?

ULLMAN: Well, since computer science is such structured thought, it would be good for them to get a very good exposure to something like sociology, or to actually study things that don't have right answers, like comparative literature. And I think foreign languages should be required. Computers use languages: very impoverished and artificial languages, but languages nonetheless. So students should learn something about the structure of languages. Being able to think, however minimally, in a foreign language, really stretches your brain.

UBIQUITY: Do you speak other languages?

ULLMAN: I speak Spanish, though it's rusty from the years of disuse. I speak enough French to get around in the world, and I can get by in broken tourist pidgin German. I think that's sort of pitiful. Many Europeans I know switch among languages with an ease that just mystifies me, and I envy that.

UBIQUITY: Well, let's switch our focus now, from languages that you may or may not be pitiful in, to a language in which you are absolutely brilliant in, and that's English, as you demonstrated both in your first book, the memoir "Close To The Machine: Technophilia and Its Discontents," and in your new novel, "The Bug", which is absolutely brilliant. How did you first get into the habit of writing? When did you become a writer?

ULLMAN: Well, I've always written. I tried to write in college, and was bad at it, and wrote some horrible poetry. So I gave up writing to take up photography. I remember sitting inside on an early spring day outside of Ithaca, New York, when the snow was beginning to melt. Spring in central New York State is a dramatically wet affair, and I was sitting inside trying to write what was turning out to be a very bad poem, and I said to myself, god, I'm trying to write about spring when what I should do is go out there and muck around in it. The person I lived with had a camera, and I just picked it up and went out, and I was converted to photography. I just felt I had to be out in the world more.

I did not write again for many years, not until the early 1980s, when I was working as a programmer. I wrote short stories and I'd send them away to magazines and get rejections, sometimes a nice note with the rejection. I wasn't under any illusion that these were groundbreaking or even good, but they were competent, and I kept doing it simply because I wanted to. Even as I was programming, I wrote a novel, a very long novel about people involved in politics in the '70's -- and oh god the manuscript was something like 760 pages, and I never really showed that to anybody. I think two people have read it, and I wisely put it away and didn't write again for several years.

I started writing again because of two people. The first was my friend Clara Basile, who got me involved in writing for The Red Herring in the days when it was a startup publication, a sort of a newsletter for venture capitalists. This was '93 or '94, I think. We did a series of pieces, I can't remember how many -- maybe fifteen? It was very good for me. It taught me to write professionally, to get over the preciousness and self-consciousness of "creative writing," to craft a paragraph, and just get on with it. After what I thought of as the failure of my first novel, I'm not sure I would ever have started writing again if not for Clara.

The other important person for my writing is Nancy Peters, who, with Lawrence Ferlinghetti, is the co-owner and co-publisher of City Lights in San Francisco. Nancy in 1994 got a proposal for a book that eventually was called "Resisting the Virtual Life." It was brilliant timing for City Lights to put out a book critical of technology at that point. Nancy said to the person who sent her the proposal, oh, you should contact this Ellen Ullman person. Nancy and I had known each other through mutual friends. I spoke with Jim Brook, the editor of the collection, and we agreed that I would write an essay about being a programmer. I thoroughly enjoyed writing it, and Harper's picked it up, reprinting sections of the essay in its "Readings" section. Then Nancy came back to me and said, well why don't you write us a little book now, something just like your essay, only longer. So that was the beginning of "Close To The Machine," and I have to thank Nancy Peters for starting me on this leg of my writing life, which actually kind of "took."

I think it's very funny: I'd always viewed writing as a kind of antidote to my life as a programmer -- as a way to go somewhere else -- but no one wanted to publish any of that. But when I actually began writing about my life as a programmer, people were very interested in publishing it. There's some kind of lesson for me there.

UBIQUITY: Tell us now about how your new novel, "The Bug," came about.

ULLMAN: After "Close To The Machine" I began to think about what to do next. I very much wanted to do a second book, to prove to myself that "Close to the Machine" wasn't some kind of fluke. So decided I'd do a collection of essays centered around a novella-length piece about a bug I'd once had as a programmer. It was a bug I couldn't fix for a full year, and it was really driving me crazy -- I mean crazy to a point where I began to wonder if I'd gotten everything hopelessly wrong about computers. Maybe my being self-taught had led me into some serious misunderstanding about how things really worked. I was becoming more and more humiliated by this bug. It was intermittent, flaky, I couldn't make it come and go reliably. It seemed to come at the worst possible moments, and though the rest of my work was going well, I knew there was this flaw in the heart of things, and it was deeply unnerving to me.

I thought, well, maybe this experience would make a good essay. It was in the middle of the dot-com bubble, and I thought a story about the flaws in computers would make a good antidote to some of that tech euphoria. So I thought I'd put this bug story together with some of the essays that I'd written -- and end up with something like "even closer to the machine."

I sat down to do this essay but everything went wrong on me. First of all, I didn't want to write about myself again. What was going on in my own life at the time didn't seem particularly interesting to other people. I felt that I couldn't convey the actual emotional content of the experience without being histrionic. I couldn't find a way to do the story justice.

So for many reasons I just kept starting it and abandoning it. I just kept throwing away and throwing away and throwing away bits and pieces and pages. (I tend to write in bits and pieces.) I finally decided I couldn't make it come together as an essay, so I decided: All right, I'll try this as fiction.

UBIQUITY: How would you tell the story of "The Bug" to somebody you met on an airplane, who asked you what it was about?

ULLMAN: I guess I'd just say it¹s about a computer programmer who has a bug he can¹t fix for a year -- and about how his life unravels as a result. In his spare time, he's working on what he calls a simulated ecosystem -- it's an early, very simple simulation based on what we'd now call chaos theory, the idea that complexity arises out of the interaction of many small, simple processes. The simulation is something he started in graduate school, before he had to drop out and get a job -- his father died, he needed money. As his working life and personal life are coming apart -- things aren't going well with his girlfriend, this terrible bug keeps coming and going without any pattern he can see -- he keeps going back to the simulation. It's a kind of lifeline for him. Some train of thought he thinks will keep him together. In the end, though, it will actually prove to be a mortal disappointment.

The story is framed and partially narrated by his tester, Berta Walton. She has a Ph.D. in linguistics and describes herself as failed academic, someone who couldn't get a position, part of the 1980s Ph.D. glut, a former member of "the lumpen professoriat." She and the programmer, Ethan Levin, have a combative relationship. And part of the story is the tension between their different worldviews and personalities.

I guess I'd say the novel is kind of a detective story. A kind of a technological mystery story because the bug -- a dead program -- is like a dead body. Someone is going to have to figure out what caused the death. That person who has to find the bug is different from a police detective, but there is something implicitly suspenseful about it.

UBIQUITY: It's more than just a detective story, it's really a thriller.

ULLMAN: Yes, I think that¹s fair. Someone warned me, "Oh, you don¹t want people to get the mistaken impression that it¹s a thriller," but I said, no, I think that would be fine. It's a book about a computer programmer, it teaches you to use a debugger, it has code samples, it describes one of the best-known cellular automata -- Conway's Game of Life -- and it's a kind of thriller. I think that calling it a thriller in this context would be just fine.

UBIQUITY: Sure, there are no cops running around shooting people, but it's about detection and has the pace of a thriller. It's really a quite brilliant book.

ULLMAN: Thank you.

UBIQUITY: What's next for your writing?

ULLMAN: I've started a novel about genetics and identity, and doing all the things for "The Bug" that need to be done to promote any new book. I'll also be giving a talk at MIT, and I've been invited to do a column for "The American Scholar."

UBIQUITY: And "The Bug" will be available through better bookstores and book sites everywhere?

ULLMAN: I would hope so.

UBIQUITY: Finally, back to Ellen Ullman the technologist. Are you still actively involved in information technology, as we speak?

ULLMAN: No. I'm not. I look at some of the open source code, and follow the developments in the open source movement, which is really the most exciting thing that's happened to programming in a very long time, because it allows programmers to reclaim the professionalism of the work. I think a lot of programming tools have all these wizards in them, and I think it's fine -- it helps simplify certain repetitive tasks. But there's a way in which not being able to see the actual code really keeps you stupid.

All these helpful wizardry tools are good when everything works as it's supposed to. But people who program understand that most of the time, things don't go as they're supposed to. And so, when things go wrong, as they will most of the time, not being able to see the code makes it very, very difficult to ferret out what's happening.

The open source movement is a reaction against corporate ownership of code -- it's an attempt to reclaim professional sovereignty over your own work, and I think it's a very important development. I like the spirit in which it's being developed. There's a way in which programming has been such a solitary, obsessional activity, leaving you pretty much alone with your own work. You really can't even talk about it to anybody, even to your co-workers, because they have their own deep tunnels that they're digging. The open source movement is a way for programming to be a social act. And I think that's very promising.

COMMENTS

POST A COMMENT
Leave this field empty