Ellen Ullmann has been casting an expert — and sometimes skeptical — eye over the tech world since the dawn of the digital era. Profile by Joy Press.
5
1
eBook
$11.99
Related collections and offers
11.99
In Stock
Overview
The never-more-necessary return of one of our most vital and eloquent voices on technology and culture, the author of the seminal Close to the Machine
The last twenty years have brought us the rise of the internet, the development of artificial intelligence, the ubiquity of once unimaginably powerful computers, and the thorough transformation of our economy and society. Through it all, Ellen Ullman lived and worked inside that rising culture of technology, and in Life in Code she tells the continuing story of the changes it wrought with a unique, expert perspective.
When Ellen Ullman moved to San Francisco in the early 1970s and went on to become a computer programmer, she was joining a small, idealistic, and almost exclusively male cadre that aspired to genuinely change the world. In 1997 Ullman wrote Close to the Machine, the now classic and still definitive account of life as a coder at the birth of what would be a sweeping technological, cultural, and financial revolution.
Twenty years later, the story Ullman recounts is neither one of unbridled triumph nor a nostalgic denial of progress. It is necessarily the story of digital technology’s loss of innocence as it entered the cultural mainstream, and it is a personal reckoning with all that has changed, and so much that hasn’t. Life in Code is an essential text toward our understanding of the last twenty years—and the next twenty.
Product Details
| ISBN-13: | 9780374711412 |
|---|---|
| Publisher: | Farrar, Straus and Giroux |
| Publication date: | 08/08/2017 |
| Sold by: | Macmillan |
| Format: | eBook |
| Pages: | 320 |
| Sales rank: | 574,926 |
| File size: | 3 MB |
About the Author
Ellen Ullman is the author of a novel, The Bug, a New York Times Notable Book and runner-up for the PEN/Hemingway Award, and the cult classic memoir Close to the Machine, based on her years as a rare female computer programmer in the early years of the personal computer era. She lives in San Francisco.
Ellen Ullman wrote her first computer program in 1978. She went on to have a twenty-year career as a programmer and software engineer. Her essays and books have become landmark works describing the social, emotional, and personal effects of technology. She is the author of the novels:By Blood, a New York Times Notable Book; and The Bug, a runner-up for the PEN/Hemingway Award. Her memoir, Close to the Machine, about her life as a software engineer during the internet’s first rise, became a cult classic. She is based in San Francisco.
Ellen Ullman wrote her first computer program in 1978. She went on to have a twenty-year career as a programmer and software engineer. Her essays and books have become landmark works describing the social, emotional, and personal effects of technology. She is the author of the novels:By Blood, a New York Times Notable Book; and The Bug, a runner-up for the PEN/Hemingway Award. Her memoir, Close to the Machine, about her life as a software engineer during the internet’s first rise, became a cult classic. She is based in San Francisco.
Read an Excerpt
CHAPTER 1
Outside of Time
REFLECTIONS ON THE PROGRAMMING LIFE
1994
I.
People imagine that 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 isn't logical — the computer is terribly logical, relentlessly literal-minded. Computers are supposed to be like brains, but in fact they are idiots, because they take everything you say at face value. I can say to a toddler, "Are yew okay tewday?" and the toddler will understand. But it's not possible for a programmer to say anything like that to a computer. The compiler complains; finds a syntax error; won't translate your program into the zeros and ones of the machine. It's not that a program can't be made to act as if it understands — it can. But that's just a trick, a trick of the code.
When you are writing code, your mind is full of details, millions of bits of knowledge. This knowledge is in human form, which is to say rather chaotic, coming at you from one perspective, then another, then a random thought, then something else important, then the same thing 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 alien how to prepare one. That is programming.
A computer program is 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 line-by-line world of computer language.
You must not lose your own attention. As the human-world knowledge tumbles about in your mind, you must keep typing, typing. You must not be interrupted. Any break in your listening causes you to lose a line here or there. Some bit comes; then — oh no — it's leaving, please come back. It may not come back. You may lose it. You will create a bug and there's nothing you can do about it.
Every single computer program has at least one bug. If you are a programmer, it is guaranteed that your work has errors. These errors will be discovered over time, most coming to light after you've moved on to a new job. But your name is on the program. The code library software keeps a permanent record card of who did what and when. At the old job, they will say terrible things about you after you've gone. This is normal life for a programmer: problems trailing behind you through time, humiliation in absentia.
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 inability to be interrupted leads to a life that is strangely asynchronous with the one lived by other human beings. It's better to send email than to call a programmer on the phone. 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 but the phone rings in real time. Similarly, meetings are supposed to take place in real time. It's not just ego that prevents programmers from working in groups — it's the synchrony problem. To synchronize with other people (or their representation in telephones, buzzers, and doorbells) can only mean interrupting the thought train. Interruptions mean certain bugs. You must not get off the train.
I used to have dreams in which I was overhearing conversations I had to program. Once, I had to program two people making love. In my dream they sweated and tumbled while I sat with a cramped hand writing code. The couple went from gentle caresses to ever-widening passions, and I despaired as I tried desperately to find a way to express the act of love in the computer language called C.
II.
I once had a job where I didn't talk to anyone for two years. Here was the arrangement: I was the first engineer hired by a startup 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 recently hired engineers and three Sun workstations. The fans of the machines whirred; the keys of the keyboards clicked. Occasionally, one or another of us would grunt or mutter. Otherwise, we did not speak. Now and then, I would have a temper outburst in which I pounded the keyboard with my fists, setting off a barrage of beeps. My colleagues might look up but never said anything about this.
Once a week, I had a five-minute meeting with my boss. I liked him; he was genial; he did not pass on his own anxieties about working in a startup. At this meeting I would routinely tell him I was on schedule. Since being on schedule is a very rare thing in software engineering, he would say, "Good, good, see you next week."
I remember watching my boss disappear down the row of cubbyhole partitions. He always wore clothes that looked exactly the same: khaki pants and a checked shirt of the same pattern. So, week to week, the image of his disappearing down the row of partitions remained unchanged. The same khaki pants, the same pattern in the checked shirt. "Good, good, see you next week."
Real time was no longer compelling. Days, weeks, months, and years came and went without much physical change in my surroundings. Surely I was aging. My hair must have grown, I must have cut it; it must have grown again. Gravity must have been working on my sedentary body, but I didn't notice. I only paid attention to my back and shoulders because they seized up on me from long sitting. Later, after I left the company, there was a masseuse on staff. That way, even the back and shoulders could be soothed — all the better to keep you in your seat.
What was compelling was the software. I was making something out of nothing, I thought, and I admit the software had more life for me than my brief love affair, my friends, my cat, my house, my neighbor who was stabbed and nearly killed by her husband. I was creating ("creating" — that is the word we used) a device-independent interface library. One day, I sat in a room by myself surrounded by computer monitors from various manufacturers. I remember looking at the screens of my companions and saying, "Speak to me."
I completed the interface library in two years and left the company. On my last day on the job, the financial officer gave me a check: it was a payment to buy back most of my stock. I knew this was coming. When I was hired I'd signed an agreement: the price of leaving before five years was the return of the stock. Still, I didn't feel free or virtuous. I put the check in my pocket, then got drunk at my farewell party.
Five years later, the company went public. For the engineers who'd stayed, the original arrangement was made good: in exchange for giving up seven years of their lives, they became very, very wealthy. As for me, I bought a car. A red one.
III.
Frank was thinking he had to get closer to the machine. Somehow, he'd floated up. Up from memory heaps and kernels. Up from file systems. Up through utilities. Up to where he was now: an end-user query tool. Next thing, he could find himself working on general ledgers, invoices — God — financial reports. Somehow, he had to get closer to the machine.
Frank hated me. Not only was I closer to the machine, I had won the coin toss to get the desk near the window. Frank sat in full view of the hallway, and he was farther from the machine.
Frank was nearly forty. His wife was pregnant. Outside, in the parking lot (which he couldn't see through my window), his new station wagon was heating up in the sun. Soon he'd have a kid, a wife who had just quit her job, a wagon with a child carrier, and an end-user query tool. Somehow, he had to get closer to the machine.
Here are the reasons Frank wanted to be closer 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. Programs and machines don't care how you live. They don't care when 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.
To express the idea of being "closer to the machine," an engineer refers to "low-level code." In regular life, "low" usually signifies something bad. In programming, "low" is good. Low is better.
If the code creates programs that do useful work for regular human beings, it is called "higher." Higher-level programs are called "applications." Applications are things that people use. Although it would seem that usefulness by people would be a good thing, from a programmer's point of view, direct people-use is bad. If regular people, called "users," can understand the task accomplished by your program, you will be paid less and held in lower esteem. In the regular world, the term "higher" may be better, but in programming higher is worse. High is bad.
If you want money and prestige, you need to write code that only machines or other programmers understand. Such code is "low." It's best if you write microcode, a string of zeros and ones that only a processor reads. The next best thing is assembler code, a list of instructions to the processor, but readable if you know what you're doing. If you can't write microcode or assembler, you might get away with writing in the C language or C+ +. C and C+ + are really sort of high, but they're considered "low." So you still get to be called a "software engineer." In the grand programmer scheme of things, it's vastly better to be a "software engineer" than a "programmer." The difference is thousands of dollars a year and a potential fortune in stock.
My office mate Frank was a man vastly unhappy in his work. He looked over my shoulder, everyone's shoulder, trying to get away from the indignity of writing a program used by normal human beings. This affected his work. His program was not all it should have been, and for this he was punished. His punishment was to have to talk to regular people.
Frank became a sales-support engineer. Ironically, working in sales and having a share in bonuses, he made more money. But he got no more stock options. And in the eyes of other engineers, Frank was as "high" as one could get. When asked, we said, "Frank is now in sales." This was equivalent to saying he was dead.
IV.
Real techies don't worry about forced eugenics. I learned this from a real techie in the cafeteria of a software company.
The project team is having lunch and discussing how long it would take to wipe out a disease inherited recessively on the X chromosome. First come calculations of inheritance probabilities. Given a population of a given size, one of the engineers arrives at a wipe-out date. Immediately another suggests that the date could be moved forward by various manipulations of the inheritance patterns. For example, he says, there could be an education campaign.
The six team members then fall over one another with further suggestions. They start with rewards to discourage carriers from breeding. Immediately they move to fines for those who reproduce the disease. Then they go for what they call "more effective" measures: Jail for breeding. Induced abortion. Forced sterilization.
Now they're hot. The calculations are flying. Years and years fall from the final doom-date of the disease.
Finally, they get to the ultimate solution. "It's straightforward," someone says. "Just kill every carrier." Everyone responds to this last suggestion with great enthusiasm. One generation and — bang — the disease is gone.
Quietly, I say, "You know, that's what the Nazis did."
They all look at me in disgust. It's the look boys give a girl who has interrupted a burping contest. One says, "This is something my wife would say."
When he says "wife," there is no love, warmth, or goodness in it. In this engineer's mouth, "wife" means wet diapers and dirty dishes. It means someone angry with you for losing track of time and missing dinner. Someone sentimental. In his mind (for the moment), "wife" signifies all programming-party-pooping, illogical things in the universe.
Still, I persist. "It started as just an idea for the Nazis, too, you know."
The engineer makes a reply that sounds like a retch. "This is how I know you're not a real techie," he says.
V.
A descendant of Italian princes directs research projects at a well-known manufacturer of UNIX workstations. I'm thrilled. In my then five years of being a consultant, the director is the first person to compliment me on what I am wearing to the interview.
It takes me a while, but I soon see I must forget all the usual associations with either Italians or princes. There will be no lovely long lunches that end with deftly peeled fruit. There will be no well-cut suits of beautiful fabrics. The next time I am wearing anything interesting, the director (I'll call him Paolo) tells me I look ridiculous.
Paolo's Italian-ness has been replaced, outer-space-pod-like, with some California New Age, Silicon Valley engineering creature. He eats no fat. He spoons tofu-mélange stuff out of a Tupperware container. Everything he does comes in response to beeps emitted from his UNIX workstation: he eats, goes to meetings, goes rollerblading in the parking lot, buys and sells stock, calls his wife solely in response to signals he has programmed into his calendar system. (The clock on his wall has only the number twelve on it.) Further, Paolo swears he has not had a cold since the day he decided that he would always wear two sweaters. Any day now, I expect to see him get out of his stock-option Porsche draped in garlic.
I know that Paolo has been replaced because I have met his wife. We are at a team beer-fest in the local programmer hangout on a Friday evening. It's full of men in tee shirts and jeans. Paolo's wife and I are the only people wearing makeup. She looks just the way I expect a no-longer-young Italian woman to look — she has taken time with her appearance, she is trying to talk to people. Across the swill of pitchers and chips glopped with cheesy drippings, she eyes me hopefully: another grown-up woman. At one point, she clucks at Paolo, who is loudly describing the effects of a certain burrito. "The only thing on earth that instantly turns a solid into a gas," he says.
The odder Paolo gets, the more he fits in with the research team. One engineer always eats his dessert first (he does this conscientiously; he wants you — dares you — to say something; you simply don't). Another comes to work in something that looks suspiciously like his pajamas. To join this project, he left his wife and kids back east. He obviously views the absence of his family as a kind of license: he has stopped shaving and (one can't help noticing) he has stopped washing on a regular basis. Another research engineer comes to work in shorts in all weather; no one has ever seen his knees covered. Another routinely makes vast changes to his work the day before deadlines; he is completely unmoved by any complaints about this practice. And one team member screens all email through a careful filter, meaning most mail is deposited in a dead-letter file. This last engineer, the only woman permanently on the project, has outdone everyone on oddness: she has an unlisted work phone. To reach her, you must leave a message with her manager. The officially sanctioned asynchrony of the unlisted phone amazes me. I have never seen anything like it.
These research engineers can be as odd as they like because they are very, very close to the machine. At their level, it is an honor to be odd. Strange behavior is expected, it's respected, a sign that you are intelligent and as close to the machine as you can get. Any decent software engineer can have a private office, come and go at all hours, exist out of normal time. But to be permanently and sincerely eccentric — this is something only a senior research engineer can achieve.
In meetings, they behave like children. They tell each other to shut up. They call each other idiots. They throw balled-up paper. One day, a team member screams at his Korean colleague, "Speak English!" (A moment of silence follows this outburst, at least.) It's like dropping in at the day-care center by mistake.
(Continues…)
Excerpted from "Life in Code"
by .
Copyright © 2017 Ellen Ullman.
Excerpted by permission of Farrar, Straus and Giroux.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
Table of Contents
CONTENTS
A Note About the Dates ix
PART ONE: THE PROGRAMMING LIFE
Outside of Time: Reflections on the Programming Life 3
Come in, CQ 18
The Dumbing Down of Programming: Some Thoughts on Programming, Knowing, and the Nature of “Easy” 39
What We Were Afraid of As We Feared Y2K 56
PART TWO: THE RISE AND FIRST FALL OF THE INTERNET
The Museum of Me 81
Fiber Optic Nights 94
Off the High 104
To Catch a Falling Knife 115
PART THREE: LIFE, ARTIFICIAL
Programming the Post-Human: Computer Science Redefines “Life” 129
Is Sadie the Cat a Trick? 160
Memory and Megabytes 171
Dining with Robots 181
PART FOUR: THREE STORIES ABOUT WHAT WE OWE THE PAST
While I Was Away 197
Close to the Mainframe 208
The Party Line 223
PART FIVE: THE HAND THAT WRITES THE CODE
Programming for the Millions 237
Boom Two: A Farewell 272
From the B&N Reads Blog
Page 1 of