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

So I got this reputation—I fixed these mysterious bugs that nobody else could fix. Fortunately, they never asked me what the bug was. Because the truth of the matter is if they’d have asked, “How did you fix the bug?” my answer would have been, “I couldn’t understand the code well enough to figure out what it was doing, so I rewrote it.”

I did that a lot on the PDP-1 time-sharing system. There were chunks of the code that I would read and would say, “This doesn’t do what I think this part of the program is supposed to be doing,” or “It’s weird.” So I’d rewrite it. The only thing that kept me working there, with that attitude, was that I had a good track record. That’s one of the things, that if you’re not good at it, you make chaos. But if you are good at it, the world thinks that you can do things that you can’t, really.

Seibel:When you left MIT, was it a hard decision at all, deciding to drop out of school?

Cosell:No. In retrospect, it was surprisingly easy. I was hating school. It was making me crazy. MIT is really a pressure-filled place. And BBN was like the Promised Land. It was wonderful. They played with computers; the company was so laid back. It was more like Project MAC than Project MAC. This was back in an era when people routinely brought their dogs in with them. So pets were padding up and down the halls; people were working day and night.

I started working part-time because I almost always had a part-time job while I was at MIT. And it just instantly felt like home. I couldn’t believe it. My MIT stuff went completely to hell so I dropped out of school and went to full-time. Then I got settled in at BBN and was much more mellow and got my head in a better place. So the following fall, which would have been my senior year, I actually re-enrolled back at MIT. And I got back in again. So that all worked out.

Seibel:Did you feel like your MIT education was a good complement to your work experience?

Cosell:The programming courses that I took when I was an MIT undergraduate stood me in good stead in some abstract way, but didn’t actually teach me very much. Mostly what did was the environment at BBN. Nobody, other than maybe Steve Weiss, was really mentoring me, but I was sucking what I needed to know from everybody.

Seibel:Obviously there were fewer computer books available then than there are now, but are there books that you found particularly useful or books that you think programmers should read?

Cosell:Hard for me to say what programmers should do now. There was certainly nothing I can remember from back then in terms of how to program. The closest was when I got my copy of Knuth’s The Art of Computer Programming and sort of digested them from cover to cover. But I would hardly recommend that as a tutorial text for people.

Seibel:You read Knuth straight through?

Cosell:Oh, it was hot stuff. I was in my prime back then. So each volume as it came out we mostly read and sucked into our heads cover to cover.

Seibel:That requires a fair bit of mathematical sophistication. Do you think most programmers need to be able to read Knuth cover to cover like that?

Cosell:I brought up Knuth as an example. I would not teach students Knuth per se for two reasons. First, it’s got all this mathematical stuff where he’s not just trying to present the algorithms but to derive whether they’re good or bad. I’m not sure you need that. I understand a little bit of it and I’m not sure I need any of it. But getting a feel for what’s fast and what’s slow and when, that’s an important thing to do even if you don’t know how much faster or how much slower.

The second problem is once students get sensitive to that, they get too clever by half. They start optimizing little parts of the program because, “This is the ideal place to do an AB unbalanced 2-3 double reverse backward pointer cube thing and I always wanted to write one of those.” So they spend a week or two tuning an obscure part of a program that doesn’t need anything, which is now more complicated and didn’t make the program any better. So they need a tempered understanding that there are all these algorithms, how they work, and how to apply them. It’s really more of a case of how to pick the right one for the job you’re trying to do as opposed to knowing that this one is an order n -cubed plus three and this one is just order n -squared times four.

If they’re interested in that it’s nice to know that Knuth is there, but no ordinary person needs to know that. But they need to know the wisdom in there. They need to know the data structures. They need to not be stunned when they see me building linked lists in Perl. When you know all of those data structures you can pick the right one. You don’t have to pick the fastest one. You don’t have to pick the one that’s cutest to implement. You can actually pick the one that best serves your data because you know the alternatives. Don’t tell Don that I fought through but didn’t have a lot of use for a lot of the gruesome numerical calculations he did to reduce those combinatorics. But boy, did I learn a lot about data structures, and that was good stuff.

Seibel:Do you have any advice for the many programmers who are selftaught?

Cosell:Write a lot of programs. That’s certainly what worked for me. Looking at the various courses I’ve taken, writing programs is what really did it. Not programming just to while away the hours but specifically, “I ought to learn something about this; why don’t I try writing a little program to do it?” That really does it.

You can’t see how these things work and how they interact until you’ve done it some. You don’t know what programming practices are dangerous until you’ve seen which ones make your programs take weeks to debug and then seen a good programmer fix it in five minutes. I don’t think you can get that from classes. Classes can give you a lot of stuff, but in the end programming is a craft you have to perfect by plying it.

If you’re lucky, you can do it at work. But even in a work environment, where you’re learning on the job, I think that to really be good you have to learn faster than your job will make you learn things. You have to supplement what your job is asking you to do. If your job requires that you do a Tcl thing, just learning enough Tcl to build the interface for the job is barely adequate. The right thing is, that weekend start hacking up some Tcl things so that by Monday morning you’re pretty well versed in the mechanics of it.

Seibel:How much of your own programming did you do for fun versus consciously doing things to learn particular techniques?

Cosell:Mostly I viewed computer programming as a means to get neat things done and I learned how to program in order to make things happen. There were things that seemed broken to me that I could fix. I thought it would be fun to do some Lisp programming not because I wanted to learn Lisp but because some of my friends across the bridge were big Lisp guys and it was all a little mysterious to me. So I wrote some programs and that just seemed like the natural thing for me to do as opposed to sitting at Dan Murphy’s knee and having him give me lectures on CONS and CDR and CAR.

Seibel:Are there areas in formal computer science that you think are particularly useful for people who ultimately want to work as programmers?

Cosell:There are a bunch of things. I know a lot of schools do a terrible job of it, but I think getting a good course in object-oriented programming in its abstract form. One of the things I fought about with some folks at a local college here was teaching object-oriented programming using C++. I asked how they make sure their students understand the distinctions between the philosophical concept of object-oriented programming versus the idiosyncrasies and weirdnesses of C++’s implementation of it.