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

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 IFstatements 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.”

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

Norvig:I don’t know if it was so much moments, but just this realization that you can’t do everything yourself. I think a lot of programming is being able 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 right abstractions so that you can use what they have. I started thinking about it in terms of, “How is this likely done?” rather than, “I know how this was done because I did it.” If I were to have done this, how would I have done it? I hope that it’s like that, and if it’s not, figure out why not, and then figure out how to use it.

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

Norvig:I think that’s true and that’s certainly something I see in the younger programmers that are coming out now. Another difference between now and then is it seems like it’s much more assembling pieces now rather than writing everything from scratch. Now, for a school assignment, someone says, “OK, I needed a website, so I used Ruby on Rails for 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 put together these pieces rather than writing everything from scratch. So I think understanding interfaces and how they go together is more important than all the details of the insides of these packages.