Seibel: And do you remember any particular aha! moments where younoticed the difference between working on something by yourself andworking on a team?

Norvig: I don’t know if it was so much moments, but just this realizationthat you can’t do everything yourself. I think a lot of programming is beingable to keep as much as you can inside your head, but that only goes so far,at least in my head. Then you have to rely on other people to have the rightabstractions so that you can use what they have. I started thinking about itin terms of, “How is this likely done?” rather than, “I know how this wasdone because I did it.” If I were to have done this, how would I have doneit? I hope that it’s like that, and if it’s not, figure out why not, and then figureout how to use it.

Seibel: Do you think that learning to work on teams that way also enablesyou to actually work on bigger things even by yourself when you’re sort of ateam spread across time?

Norvig: I think that’s true and that’s certainly something I see in theyounger programmers that are coming out now. Another differencebetween now and then is it seems like it’s much more assembling piecesnow rather than writing everything from scratch. Now, for a schoolassignment, someone says, “OK, I needed a website, so I used Ruby on Railsfor this, and I used Drupal for that part, and then I had this Python script,and then I downloaded this statistical routine,” and it’s all scripting to puttogether these pieces rather than writing everything from scratch. So I thinkunderstanding interfaces and how they go together is more important thanall the details of the insides of these packages.

Seibel: And do you think that changes the kind of people who can besuccessful at programming now?

Norvig: I think the people that are really successful are the same—at leastthat’s what I see around here. But, yeah, it is a little bit more of, “Can Iquickly get an understanding of what I need,” and less of, “I need completeunderstanding.” I think some of it is bravado, this willingness to say, “I’m justgoing to go ahead and do it,” the fearlessness of saying, “I don’t understandeverything that’s going on, but I went into the documentation and I learnedthese three things. I tried it and it worked, so I’m just going to go ahead.”That gets you to a certain point, but I think to really be a good programmer,you can’t just do that. You have to understand a little bit more, and say, “Isit safe, what I’m doing here? Or what are the failure cases? Sure, I tried itonce and it worked, but is it always going to work? How do I write testcases to show that and to understand it a little better, and then once I’vedone that, can I extract what I’ve done and publish a new tool that otherpeople can use because I’ve put these pieces together in a certain way.”

Seibel: How did you like to work on a team when you were aprogrammer? Is it better to take the problem and split it up so everybodygets their piece? Or do you like the XP model of pair-program everythingand everybody owns all the code collectively?

Norvig: I guess it’s more break it up. Steve Yegge’s got this “Good Agile,Bad Agile” piece. I think he’s about right. Ten percent of the time it is areally good idea to sit down together because you want that sharedunderstanding. I think most of the time you’re not going to be as effective.

If you have two good programmers, it’s better for them to workindependently and then debug each other’s work afterwards rather than tosay, “We’ll take a 50 percent hit just for that added set of eyes.”

I think it is important to get together when you’re figuring out what it is youwant to do both in terms of brainstorming what is the problem we’re tryingto solve and what is the functionality going to be here? You don’t evenknow what the product is before you start. That you really want to dotogether. Then you get to the point of saying, “OK, now we know what wewant to do. How are we going to divide it up?” That you want to dotogether. Once you have a pretty good idea, I think you’re better offspending most of the time on your own. You want feedback, so I think youshould require every piece of code to be reviewed by another set of eyes,but it doesn’t have to be real-time, when you’re writing it.

I remember the IBM master-programmer idea, and that just seemed like thedumbest thing I have ever heard of. Why would anybody want to subjectthemselves to being a gopher for the one real programmer?

Seibel: I’m surprised you think the master-programmer model is such adumb idea. In your “Teach Yourself Programming in Ten Years” essay youmake the point that programming is a skill that, like many skills, probablytakes about a decade to really master. And lots of crafts hadmaster/journeymen/apprentice kind of hierarchies. So maybe nobody wantsto be the apprentice, but maybe it isn’t crazy to say that somebody who’sbeen through that decade-long learning experience should be doing differentwork than someone who’s fresh out of school.

Norvig: I think the best part of the apprentice approach is that you get towatch the master, and I would like to see more of that. So I guess that’sanother use of pair programming. I can see that it’d be really good, if youwere inexperienced, to watch somebody who’s much more experienced.Particularly for the types of things that aren’t taught as much, like debuggingskills. Anybody can learn algorithms and so on, but they don’t really teachdebugging and watching someone, and saying, “Wow, I never thought ofdoing that,” that’s really useful.

But I think part of the reasons why you had master and apprentice isbecause the materials were rarer. When you were doing goldsmithing,there’s only so much gold. Or when the surgeon’s operating, there’s onlyone heart, and so you want the best person on that and you want the otherguys just helping. With coding, it’s not like that. You’ve got plenty ofterminals. You’ve got plenty of keyboards. You don’t have to ration it.

Seibel: Speaking of things that aren’t taught as much, you’ve been both anacademic and in industry; do you feel like academic computer science andindustrial programming meet in the right place?

Norvig: It’s a big question. I don’t think there’s a lot of waste in computer sciencecurriculum. I think that it’s mostly very good stuff to know. I thinkgoing to school is useful, but it’s not everything that you need to besuccessful in the industry or to build systems. I do think that curriculum inmany schools has been slow to adapt. There are a number of places wherethat comes into play: working in a team is not taught so much in school.This idea of being able to put the pieces together is not really taught there,but somehow the kids pick it up anyway, so maybe that’s OK. At Googlewe’re certainly interested in this large-scale cloud computing, parallelcomputing, and so forth. That’s not taught so much, although I think there’sa lot of interest in it. So I think they lag behind a little bit, but I think it’s stilluseful.

Seibel: And are there any areas where academics are out in front ofindustry? Where industry is ignoring good stuff about how we ought tobuild software.

Norvig: I think to some degree. Probably the best example was the modelchecking where Intel wasn’t really paying much attention and then they hadthis big recall and they lost a lot of money because they had a bug in theirmultiply. And then they started to pay attention, and they went to anacademic and said, “What can you do to help us?” So there actually wassomething there. And now it’s an integral part of what they do, so that wasa good example. It seems like programming languages, probably not somuch. There’s a lot of work going on but you don’t see a big impact of thenewer programming languages. Operating systems, a little bit. We’resupporting this RAD Lab at Berkeley with Dave Patterson and so on. Theyhave some good ideas—how to make reliable systems. But it’s certainly thecase that industry has the larger, bigger problems. They may not have all theanswers to them—but they’re hitting them harder than in the universitysetting.