Seibel: People are going to hate you when you discover that actually, really tiny monitors make people more productive.

Norvig: Right. And if providing quiet is important, then you should probably do that, but on the other hand, if providing communication between team members is important, then you should do that, and how do you balance those two?

I just started thinking about what’s the right way to do that. How do you set up an experiment? What do you track? Do we have numbers already that we could make use of just by adding in some kind of questionnaire? Do we have to set up an experiment?

Seibel: It’s often claimed that there are orders of magnitude differences in productivity between programmers. Yet I read somewhere some criticism of those claims, saying the studies that found that were done quite some time ago, and a lot of things have changed about programming since then that could have accounted for the differences—such as some people in the study were still using batch processing techniques while other people were using timesharing programming environments.

Norvig: I don’t think that’s all of it, because I think there were some differences within the same organization using more of the same tools. I also remember there were criticisms of some of the studies of finding correlation, but not knowing cause and effect. If you found that the programmers in the big corner offices were more productive, is that because you reward the good programmers with the offices, or is it because the offices makes them better? You can’t really come to a conclusion.

Seibel: Do you still enjoy programming as much as when you were starting out?

Norvig: Yeah, but it’s frustrating to not know everything. I’m not doing it as much, so I forget a little bit. And there are all these new things. I really should redesign my web site and it should have JavaScript on the client side. It should have PHP or something like that, and I just haven’t gotten up the momentum to learn all that stuff and be able to do it.

Seibel: Do you think programming is a young person’s game?

Norvig: I think it helps in some ways. We certainly have a range of people here that are exceptionally good at all levels and all ages. I think the advantage of being young is it’s important to grasp the whole program, the whole problem, in your head—being able to concentrate. And I think that’s easier when you’re younger, because your brain is better at it, or maybe it’s just that you have less distractions. If you have kids, and family, and so on, you just can’t devote as many consecutive hours as when you don’t. So that’s part of it. But on the other hand, you’ve got this range of experience, so you can make up for that in some ways by being able to do more because you know how to do it.

Seibel: One of the aspects of the modern style of programming, as you were saying, is that programmers have to absorb things quickly. How do you tackle the problem of understanding a big pile of code, none of which you’ve ever seen before?

Norvig: I think you do a mix of statically and dynamically. You start reading the code and trying to make sense of it and then you get some traces of what calls what, and where most of time is spent, and what’s the flow through it. Then try to do something. Say, “I’m going to make this trivial little change.” Or go to the issues database and say, “I’ll take this one.” In order to do that, I have to learn a little piece of it. There’s only a little piece, but you get that done and you move on to the next one.

Seibel: Have you ever done literate programming a la Knuth?

Norvig: I never used his tools per se. I’ve certainly written macros and so on. And I’ve used the Java docs and things like that. In many ways, Lisp programming encourages you to make your own system as you go, and so it ends up being literate in that way. You find your own macros for your own application-specific programming, and part of that is the documentation, part of it’s the data, and part of it’s the code, so I’ve certainly done that. Then more recently, in whatever language I’m using, whether it’s Java, or Python, or whatever, I’ve certainly been careful to write test cases, and document around that.

You look at Knuth’s original Literate Programming, and he was really trying to say, “What’s the best order for writing a book,” assuming that someone’s going to read the whole book and he wants it to be in a logical order. People don’t do that anymore. They don’t want to read a book. They want an index so they can say, “What’s the least amount of this book that I have to read? I just want to find the three paragraphs that I need. Show me that and then I’ll move on.” I think that’s a real change.

Seibel: I wonder if there isn’t a way to write modern-style literate programming. Certainly Knuth’s tools give you an index and beautiful crossreferencing. I wonder if perhaps a modern approach to literate programming just would organize the book differently—both as a whole program and as a bunch of pieces that you can understand in bits?

Norvig: I don’t know. I think he was solving a problem that doesn’t exist anymore to a large degree. Part of it was because he wanted to put it in a linear order rather than in a web-like or a searchable order. I think part of it was the limitations. I think he was using Pascal originally. And there it’s pretty strict in terms of what had to be declared first and not necessarily in the order you want. Modern languages are more free in that order, so I think it’s less of an issue now.

Seibel: You mentioned reading Strachey’s checkers code in Scientific American. And in your “Teach Yourself Programming in Ten Years” essay, you talk about the importance of reading code. What code did you read coming up?

Norvig: I read a lot of the Symbolics’s code, because that was available when I was at Berkeley.

Seibel: Was that just because it was available and was interesting? Or were you reading it to try to understand some behaviors you were observing?

Norvig: Both. I sometimes just tried to figure out how things work and sometimes I needed it to solve a problem.

Seibel: So when you’re reading just for general edification, how do you approach that?

Norvig: I think it’s probably interest-driven. “Gee, this file system allows you to read files across the net using the same protocol that you use locally on your machine—I wonder how it does that?” And so you’ll say, “Maybe it’s in the open function.” You look there, and say, “Oh, that calls this other thing.” And you look there, and eventually you say, “Oh, this is how it does it.”

Seibel: Have you read any of Knuth’s literate programs in book form?

Norvig: I’ve certainly picked up the books and flipped through them. I could say I glanced at them, but I haven’t studied them.

Seibel: What about The Art of Computer Programming? Some of the people I’ve talked to on this have absolutely read it from cover to cover. Some people have it on the shelf and use it as a reference. And some people just have it on the shelf.

Norvig: At one point I had it as my monitor stand because it was one of the biggest set of books I had, and it was just the right height. That was nice because it was always there, and I guess then I was more prone to use it as a reference because it was just right in front of me.

Seibel: But you had to lift up the monitor every time you wanted to look at it?

Norvig: No, I had the box set. You had to pull hard, but you could pull one of the box. Now I’m less likely to use any book for reference—I’m just likely to do a search.

Seibel: Just because it’s more convenient?

Norvig: It’s convenient. I think it’s also that I’m probably more goaloriented. Knuth is good if you say, “I want to know everything about this subject.” But usually I’m saying, “I want to know if A is better than B,” or, “I want to know the asymptotic complexity of this, and once I’ve got that, I don’t need all the details of how we got there.”