I really believed that computers were deterministic, that you couldunderstand what they were supposed to do, and that there was no excusefor computers not working, for things not functioning properly. Inretrospect, I was surprisingly good at keeping the system running, putting innew code and having it not break the system.

That was the first instance of something I got an undeserved reputation for.I know that my boss, and probably some other of my colleagues, have said Iwas a great debugger. And that’s partly true. But there’s a fake in there.

Really what I was was a very careful programmer with the arrogance tobelieve that very few computer programs are inherently difficult. I wouldtake some piece of code that didn’t look like it was working and I would tryto read it. And if I could understand, then I could usually see what waswrong or poke around with it and fix it. But sometimes I would get a pieceof code—often one that other people couldn’t make work—and I wouldsay, “This is way too complicated.”

So I would think through what it was supposed to do, throw it away, andwrite it again from scratch. Some of the folks I worked with—like WillCrowther—who are terrific programmers, couldn’t tolerate that. Theywould believe that by doing that, I would probably have fixed the 2 bugs thatwere there and introduced 27 new bugs. But the fact is, I was good at that.So I would rewrite stuff completely and it would be organized differentlythan the original programmer had organized it because I had thought aboutthe problem differently. Typically, it was simpler than it used to be, or atleast simpler to my eyes. And it would work.

So I got this reputation—I fixed these mysterious bugs that nobody elsecould fix. Fortunately, they never asked me what the bug was. Because thetruth of the matter is if they’d have asked, “How did you fix the bug?” myanswer would have been, “I couldn’t understand the code well enough tofigure 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 thecode that I would read and would say, “This doesn’t do what I think thispart of the program is supposed to be doing,” or “It’s weird.” So I’d rewriteit. The only thing that kept me working there, with that attitude, was that Ihad a good track record. That’s one of the things, that if you’re not good atit, you make chaos. But if you are good at it, the world thinks that you cando things that you can’t, really.

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

Cosell: No. In retrospect, it was surprisingly easy. I was hating school. Itwas making me crazy. MIT is really a pressure-filled place. And BBN was likethe Promised Land. It was wonderful. They played with computers; thecompany 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 withthem. So pets were padding up and down the halls; people were workingday and night.

I started working part-time because I almost always had a part-time jobwhile 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 wentto full-time. Then I got settled in at BBN and was much more mellow andgot my head in a better place. So the following fall, which would have beenmy 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 toyour work experience?

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

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

Cosell: Hard for me to say what programmers should do now. There wascertainly nothing I can remember from back then in terms of how toprogram. The closest was when I got my copy of Knuth’s The Art ofComputer Programming and sort of digested them from cover to cover. But Iwould 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 volumeas 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 thinkmost 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 studentsKnuth per se for two reasons. First, it’s got all this mathematical stuff wherehe’s not just trying to present the algorithms but to derive whether they’regood or bad. I’m not sure you need that. I understand a little bit of it andI’m not sure I need any of it. But getting a feel for what’s fast and what’sslow and when, that’s an important thing to do even if you don’t know howmuch faster or how much slower.

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

If they’re interested in that it’s nice to know that Knuth is there, but noordinary person needs to know that. But they need to know the wisdom inthere. They need to know the data structures. They need to not be stunnedwhen they see me building linked lists in Perl. When you know all of thosedata structures you can pick the right one. You don’t have to pick thefastest one. You don’t have to pick the one that’s cutest to implement. Youcan actually pick the one that best serves your data because you know thealternatives. Don’t tell Don that I fought through but didn’t have a lot of usefor a lot of the gruesome numerical calculations he did to reduce thosecombinatorics. But boy, did I learn a lot about data structures, and that wasgood 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 reallydid it. Not programming just to while away the hours but specifically, “Iought to learn something about this; why don’t I try writing a little programto do it?” That really does it.

You can’t see how these things work and how they interact until you’vedone it some. You don’t know what programming practices are dangerousuntil you’ve seen which ones make your programs take weeks to debug andthen seen a good programmer fix it in five minutes. I don’t think you can getthat from classes. Classes can give you a lot of stuff, but in the endprogramming 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 tolearn faster than your job will make you learn things. You have tosupplement what your job is asking you to do. If your job requires that youdo a Tcl thing, just learning enough Tcl to build the interface for the job isbarely adequate. The right thing is, that weekend start hacking up some Tclthings so that by Monday morning you’re pretty well versed in themechanics of it.