Seibel: After school you got hired directly into the Bell Labs; how did that happen? It doesn’t sound like you were a classical academic researcher at that point in your career.

Thompson: I just drifted. It was hard to describe. I certainly wasn’t in school in any real sense. In the formal sense, yes, I was. One of my professors, who is actually a very good friend, sicced the Bell Labs recruiter on me. But I wasn’t looking for a job. In fact, I had absolutely no ambitions; nothing. And he made me appointments to see him in his little recruiting booth, and I either slept through them or told him I wasn’t interested. And he kept after me. At some point he called me and said that he wanted to come over and see me. So he came over to my apartment. And said that he wanted me to come out and interview at Bell Labs. I told him no. And he said, “It’s a free trip. You can do what you want to out there.” And I say, “Well, up front I’ll just tell you that I’m not interested in a job. I’ll be glad to go for a free trip ’cause I have friends on the East Coast. I’ll go visit them.” And he says, “Fine.” So that was the interview that I got into. And I went and spent my two days at Bell Labs and then rented a car and went up and down the East Coast visiting my high-school friends that were spread out all over everywhere.

Seibel: Obviously there was something that the folks at Bell Labs saw in you and said, “We should get this guy into our lab.”

Thompson: I don’t know their side of it. My side of it is that these are people that I was reading the papers of in the classes I was taking/teaching. And I knew them by name and reputation. And they were still doing fun things. To me, work was work and these guys weren’t working. They were having a good time. Just like school.

Seibel: And so what kind of things did you do when you first arrived there?

Thompson: Bell Labs was in the MULTICS project and I was hired in to work on MULTICS. And I did. I played with the machines, booted up MULTICS, and did my little piece of it. At some point, Bell Labs decided that MULTICS wasn’t for them, and they backed out of the project.

But they had these MULTICS machines which were special-purpose machines that were just sitting around idle until someone could cart them away. So for approximately a year I had this machine that was monstrous. There are maybe two or three of us that used it. So I started doing operating-system stuff, trying to get a little operating system up and running.

It was insanely hard because it was a real complex computer. But I got it up where it would sit there and say hello on 50 Teletypes around the building. And then it went out the door. So I shopped around then and found some other unused machines and essentially built Unix on these very, very small PDP machines.

Seibel: Did you have the time to do that because your bosses knew that that’s what you were doing and said this is a good research project, or was it just because you were in between jobs?

Thompson: No, I was sort of incorrigible, to be honest. I suspected that I would eventually get fired, but it didn’t bother me. We were supposed to be doing basic research but there was some basic research we should be doing and some basic research we shouldn’t be doing. And just coming out of the ashes of MULTICS, operating systems was one of those basic research things we shouldn’t be doing. Because we tried it, it didn’t work, it was a huge failure, it was expensive; let’s drop it. So I kind of expected that for what I was doing I was going to eventually get fired. I didn’t.

Seibel: How do you design software? Do you scribble on graph paper or fire up a UML tool or just start coding?

Thompson: Depends on how big it is. Most of the time, it sits in the back of my mind—nothing on paper—for a period of time and I’ll concentrate on the hard parts. The easy parts just fade away—just write ’em down; they’ll come right out of your fingertips when you’re ready. But the hard parts I’ll sit and let it germinate for a period of time, a month maybe. At some point pieces will start dropping out at the bottom and I can see the pyramid build up out of the pieces. When the pyramid gets high enough in my mind, then I’ll start at the bottom.

Seibel: But you’re not just building leaves—you know the structure they’re going to fit into.

Thompson: Suppose someone is describing something to me from postulates like, “Here’s a computer and here are the op codes.” I can visualize the structure of programs and how things are efficient or inefficient based on those op codes, by seeing the bottom and imagining the hierarchy. And I can see the same thing with programs. If someone shows me library routines or basic bottom-level things, I can see how you can build that into different programs and what’s missing—the kinds of programs that would still be hard to write. So I can envision that pyramid, and the problem is to try and decompose it and get the bottom pieces.

Modern programming scares me in many respects, where they will just build layer after layer after layer that does nothing except translate. It confuses me to read a program which you must read top-down. It says “do something.” And you go find “something.” And you read it and it says, “do something else” and you go find something and it says, “do something else” and it goes back to the top maybe. And nothing gets done. It’s just relegating the problem to a deeper and deeper level. I can’t keep it in my mind—I can’t understand it.

Seibel: So why not still read bottom-up? The leaves are there, somewhere.

Thompson: Well, you don’t know what are leaves and what aren’t. If it’s well described you can read the English and get it and then you don’t have to read the code. But if you’re actually just given a bunch of code and told, “Read it and try and make it better or try and make it do something else,” then typically I read it top-down.

Seibel: Do you ever write down anything before you start writing code?

Thompson: I usually write down data structures before I write down code. I don’t write down algorithms—no flowcharts, or stuff like that. But the stuff you have to refer to on almost every line of code—data structures.

Seibel: If you’re writing a C program, does that mean C code that would define those data structures?

Thompson: No, little boxes with arrows and stuff.

Seibel: So you’ve got this big picture, the pyramid. How much do you stick to that plan once you start coding?

Thompson: I don’t stick to code. If I find a different partitioning halfway through, I’ll just hack and go over it. A lot of people I know, when they write a line of code, it’s concrete from then on for the rest of life, unless there’s a bug. Especially if they write a routine with an API and scribble the API somewhere on an envelope or an API list—then that’s it. It’ll never change, no matter how bad it is. And I’ve always been totally willing to hack things apart if I find a different way that fits better or a different partitioning. I’ve never been a lover of existing code. Code by itself almost rots and it’s gotta be rewritten. Even when nothing has changed, for some reason it rots.

Seibel: How do you decide when code needs to be thrown away?

Thompson: When it’s hard to work on. I do it much quicker than most people do. I’ll throw away code as soon I want to add something to it and I get the feeling that what I have to do to add it is too hard. I’ll throw it away and start over and come up with a different partitioning that makes it easy to do whatever I wanted to do. I’m really quick on the trigger for throwing stuff out.

Seibel: Is that true working with other people’s code as well?