Peter Seibel - Coders at Work - Reflections on the craft of programming

Thompson:Just his stuff in the early papers. Nothing recent.

Seibel:And are there books that you think are particularly important—that either were important to you or that you would recommend people to read?

Thompson:I don’t read beginning programming books, so I have trouble recommending such things. If I have to learn a new language or something I’ll try to find a book. I prefer much denser books that just give me the syntax and semantics rather than chatting me up and telling me what’s good style and what’s bad style.

When I taught, I would have to select a textbook for my course and would read all of the textbooks in the area and have to make a selection. So at two points in time, I knew the basic literature for those courses. But outside that I don’t read.

Seibel:When you were inventing Unix you had your plan to do the four pieces that would actually give you an operating system. Then your wife and kids went away, leaving you free to hack for a month. I assume you put in some long hours in that month. Why do we do that? Is it necessary? Is it just because it’s fun?

Thompson:You do it when you’re driven. I don’t think I could have not done it. The other thing is when the wife and kid are around you have this synchronizing to a 24-hour cycle. When they go away, I don’t have a 24-hour cycle. There’s nothing that keeps me and the sun together. And so I typically sleep on a 27- or 28-hour cycle, sleeping 6 hours. So I drift. When I get to sleep until I wake up I’m in better shape to work than if I get to sleep and get up when the kid starts screaming.

Seibel:So that’s when you’re driven by a project and you wake up wanting to get to the computer to start writing more code. But people also work long hours because we have this idea that we’ve got to get this product out the door and the way to do it is for everyone to work 80, 100 hours a week.

Thompson:That generates burnout. Excitement programming, I never ever felt stress. I’ve been in other situations too where deadlines—external deadlines—generate stress. That’s not fun; I don’t like that.

Seibel:You burn out at the end, which is obviously bad, but in terms of getting things done in the short term, does it work?

Thompson:Usually you’re in a position where such a thing is continual. That as soon as that deadline is over another one starts coming up over the horizon. If you’re constantly under deadlines like that, then the next one you’ll have less enthusiasm and pretty soon you just can’t live like that. I can’t.

Seibel:Tied up with trying to meet deadlines is being able to estimate how long things are going to take. Can you estimate how long it’s going to take to write a given piece of code?

Thompson:It depends on whether I’m writing it for me or writing it for production. I can if I’m writing for me. I can live with the quirks. I can not do the extra ten percent. I can avoid the gaping holes that I know are in there. Things like that. I can produce it and then clean it up at leisure and still use it. Maybe that’s a different definition of finished . But if you’re doing it for production then usually there are other people involved and coordination—I can’t estimate that.

Seibel:In one 1999 interview you said you didn’t think much of Linux, and got the Linux guys all up in arms. What do you think of it now about a decade later, and it’s taking over the world?

Thompson:It’s much more reliable—there’s no doubt about that. And I’ve looked at the code occasionally. I don’t look at it as much as I used to. I used to, for Plan 9. They were always ahead of us—they just had massively more resources to deal with hardware. So when we’d run across a piece of hardware, I’d look at the Linux drivers for it and write Plan 9 drivers for it. Now I have no reason to look at it. I run Linux. And I occasionally look at code, but rarely, so I can’t really tell whether the quality has gotten better or not. But certainly the reliability has gotten better.

Seibel:Do you ever read code just for fun?

Thompson:In the past I used to; less so now. When I first came here I did it just to try and get the feel of the place. You’ve got to. There’s so much unsaid that you’ve got to know.

Seibel:Would you pick a program and completely understand it, or were you just sort of looking for how do they do things around here?

Thompson:A little bit of both. I’d certainly try to pick the big libraries at first. I’d look at the main programs of some of the things. The programming style here at Google is so bizarre. They take a subroutine call, package it as an RPC, and store it somewhere static. Which means anybody can call it at any time for any reason. And then they call generic listening kind of code and somebody somewhere gets a message, goes off and finds that, and makes that subroutine call.

Seibel:So that’s a mechanism for distributed computation.

Thompson:Yeah. That’s all this place does. It’s very hard to read. So you go off and you start reading the binding code. And then this code. And then the general IPC. That gets you a handle into where you can actually start reading stuff and understanding stuff. Before that, you can’t understand a thing.

Seibel:When you work on a team, what’s the structure that you like?

Thompson:Just working with good, compatible people.

Seibel:When you’re working with compatible people, do you favor strong code ownership: “I wrote this piece of code; it is mine and I’m responsible for it,” or more shared ownership: “We all own this code together and anyone can do what they see fit.”?

Thompson:I’ve always worked halfway in between. There’s somebody who owns it and if you have a problem with it, you mail them or tell them and their job is to fix it. And then at some point they disappear, they don’t want it, they don’t fix it, they’re not responsive—then you fix it. The catchphrase is, “You touched it last.” You own it. So it’s halfway between. You don’t have a bunch of people going in and modifying the code willy-nilly. It’s all filtered through an owner. But that owner can change pretty easily.

Seibel:These days there are folks who advocate pair programming, meaning two people working at one keyboard. Have you ever worked that way?

Thompson:Something small can be done like that. Very often I’ll be typing and somebody else, who will obviously be faster at it than I, will sit down and they’ll type and I’ll talk. I’ve done that on orders of minutes to hours, very few hours, to get one thing done that both of us could have done separately.

Seibel:And did you find that the result was better or it got done faster?

Thompson:The result isn’t better. Probably debugging is faster—as you’re typing, someone can catch a bug over your shoulder. So I think it will generate fewer bugs as you go. But I didn’t find it as a philosophy as a way to go—it just happens.

Seibel:Do you still enjoy programming?

Thompson:Yes. I like small programs. Small, meaning you can do it in a month. If you’re trying to do some monster task that takes a year, I can’t keep in it that long.

Seibel:Was that always the case, or have you lost the energy for longer projects?

Thompson:I don’t know. It depends on the actual thing. Something big that takes years, like an operating system, you subdivide that and there are lots of fun pieces, so that counts as multiple small things as opposed to one big thing. But there are lots of things that are just one big thing, and those I think I’ve always found difficult. I need gratification, feedback. And if you have to sit there and work and work and work for days, months and see nothing except a pile of code, then I have trouble doing that.