Seibel: So that was the first interesting code you read; what was the first interesting program you wrote?

Norvig: I guess it was probably the Game of Life. It was actually an assignment for the class. I quickly did the assignment, and of course then we didn’t have the nice display screens. I didn’t have my 30-inch monitor—I had the teletype with the yellow paper. I said, “This is a waste, printing out one small field”—they probably wanted us to do a ten-by-ten field—“and then printing out the next one and the next one.” So I said, “Let’s print out five generations in a row.” And I remember that you couldn’t have threedimensional arrays in BASIC, and for some reason I couldn’t even have a bunch of two-dimensional arrays. It’s like they ran out of memory or something. So I had to figure out how am I going to have five or six across of these two-dimensional arrays, and that’s when I discovered bit fields.

Seibel: So given the constraints on memory, you rolled your own storage for that much data. Had you been taught about bit arrays and figured out how to apply them, or did you go digging through the manual and discovered, “Oh, look, here’s this PEEK and POKE” or whatever it was?

Norvig: Well, I was storing a zero or one in each of these locations, and I needed to store more stuff somewhere, and I said, “Oh, store other numbers there.” In fact, I don’t even remember if I did bit store. I might’ve done digits—decimal rather than binary—because the binary stuff hadn’t really been exposed to us in an interesting way. And then I got to add in things, like, is it repeating and if so, with what cycle. You couldn’t do that when you were just keeping one previous generation.

Seibel: When you were coming up as a programmer, did you do things specifically to improve your skill as a programmer, or did you just program?

Norvig: I think I just programmed. Certainly I would do things because they were fun. Especially when I was a grad student and I was less beholden to schedules. I’d say, “Oh, here’s an interesting problem. Let’s see if I can solve that.” Not because it’s progress on my thesis, but just because it was fun.

Seibel: And you studied computers in college but didn’t major in computer science, right?

Norvig: When I started, the computer classes were part of the appliedmath department. By the time I graduated there actually was a computer science department, but I stuck with math as my major. It felt like doing all the requirements for a computer-science major was like majoring in IBM. You had to learn their assembly language, you had to learn their 360 operating system, and so on. That didn’t seem like much fun. There were some courses that I liked and I took those, but I didn’t want to go through all the requirements.

After college I worked for two years, for a software company in Cambridge. And after two years I said, “It took me four years to get sick of school and only two years to get sick of work, maybe I like school twice as much.”

Seibel: What were you doing for them?

Norvig: Their main product was a software-design tool set, and they also did software consulting of various kinds. The founders had worked at Draper Labs in Cambridge on the Apollo mission and other things like that; they had Air Force connections and they were a government contractor. They had this idea of how software should be designed. I never believed in the whole idea, but it was fun.

I remember one of the projects we had there, at this company, was to write a flowchart drawer. The idea was that it would parse your program and generate a flowchart for it. Which was perfect because that’s the way people always use flowcharts. You’re supposed to write them ahead of time but you really never do—you write them after the fact. And it was clever in that it had a sort of partial grammar so you could take a program that wasn’t even quite syntactically correct and it would gloss over the parts that it couldn’t parse. It would have to know how to parse the IF statements because those made different blocks and so on but the other stuff it just said, “Well, whatever is there just throw it into a block.” We got this contract to generate this thing and they specified that they wanted to run it on a Unix system. So we borrowed a machine at MIT and used all the Unix tools, yacc and stuff, for the compiler. And at the last minute they said, “No, we’re going to install it on a VMS system.” So all of the sudden, yacc wasn’t there. But we said, “That’s OK, we don’t need it—we just needed it to generate the tables and that’s done.”

Seibel: As long as your grammar never changes, you’re OK.

Norvig: Right, and so we delivered it and they were happy and then—of course—the grammar changed. And we didn’t have access to any Unix machines anymore. So I ended up having to patch the grammar by understanding the tables and saying, “Here’s a jump to this other state—OK, I’ll invent a new state here and jump to that one instead.”

Seibel: And was that really the right solution—did you ever consider just writing a new parser?

Norvig: I probably should have. But, you know, it was just this one little fix.

Seibel: And you didn’t get caught in the trap of every three weeks they come around with a new change to the grammar?

Norvig: Well, then I went off to grad school. Somebody else had the problem and I don’t know what happened.

Seibel: Not your problem anymore. So you got your PhD. Is there anything that you wish you had done differently about how you learned to program?

Norvig: I ended up in industrial settings, so maybe I would’ve wished to have done more of that earlier on. I did learn to do it, but I was in school and in grad school for a long time. That was a lot of fun, too, so I don’t have any regrets.

Seibel: What were the things you had to learn about industrial programming?

Norvig: About having schedules, and keeping team members and customers and managers happy. When you’re a grad student, you don’t have to do that; just show up to your adviser every now and then.

I guess the biggest change was going from one person to a team and figuring out how those kinds of interactions work. That’s something you don’t normally get in school. I guess some of the schools are starting to bring that into the curriculum more. When I was in school, working as a team was called cheating.

Seibel: For people who are going into industry, are there other skills, beyond just the ability to write code, that people should develop?

Norvig: Getting along with people is the main thing. Being able to understand the customer is important: to know what it is you want to build and whether what you have is right. Being able to interact with them and then interact with your teammates. And interact with people higher up in the company and your customers when you go out and see them. There are all different social relations and they require different skills.

Seibel: Has programming become a more social activity than it used to be?

Norvig: I think so. I think the computer used to be more segregated. And in the old days it was mostly batch processing, so the interface was so much simpler. It was possible to do this kind of waterfall design where you said, “The input is going to be this deck of cards, and the output is going to be a report that has this number in this column.”

It probably wasn’t a very good idea to specify it that way. Probably right from the start you should have had more interaction with the customer. But it seemed more separable. Now everything seems more fluid and interactive so it makes more sense to say, “Rather than have a complete specification from the start, just get customers in the room and start brainstorming.”