One of the really good guys at BBN ended up working a perfectly normalschedule and finished his PhD dissertation just by being astoundinglydisciplined. He worked every Saturday on his thesis and he worked eveningson this and that. Part of it, I guess, is being organized. It is much easier to dosomething if you can do it all the way through, at which point you don’thave to think about being organized or careful or putting it down andpicking it back up, because when you’re done you can forget about it. I’vebeen learning that recently since my life is more normal now. I programaround the cracks, putting things down and picking things back up. I find thatif I don’t work on it again for two to three weeks it’s surprisingly hard topick it back up. Often when I am lagging on some little personalprogramming thing and I really want to get it done, I try to say, “OK, I’mgoing to be like the people who exercise. I’m going to do it a couple hoursevery morning.” That mostly doesn’t work for me. What happens is at somepoint I get bored with having it not be done and I’ll spend a day or two on itand get it done.

I can, in bursts, get the kind of focus I used to have, but not so wellanymore. So I think that makes this kind of special, fancy programming—what thetrue hackers do—more of a young person’s game. I have to admit almost all ofthe people I know who did stellar things when they were young did it intensely.It’s hard for me to think of any folks in the really stellar category who didit just a couple hours a day as if it were a job. Almost everyone I know woulddo it with this burst of maniacal focus and intensity and then get it done. Butthe focus is hard. It really wears you out. It certainly used to wear me out.

Seibel: Would you consider yourself a scientist, an engineer, an artist, acraftsman, or something else?

Cosell: A blend of those, obviously. I don’t consider myself a scientist, as Iunderstand what scientists do. I’d like to believe I consider myself acombination of an artist and a craftsman. The way I do engineering is as acombination of art and craft.

Seibel: Let me first ask about the engineering part. There are certainlyfolks, like Watts Humphrey and the folks at the Software EngineeringInstitute, who say programming should be an engineering discipline just likebuilding bridges. People can build bridges and they can predict how long it’sgoing to take, and the bridges, for the most part, don’t fall down.

Cosell: Exactly right. The analogy is very good except they put a nonsequitur in the middle of it. It turns out that the guy that designs the bridgeso it won’t fall down is not the guy that strings the cables or that inspectsthe cables to make sure the steel was right or pours the concrete or doesany of those other things.

Programming is in that regard an engineering discipline. You have to knowwhat to do. You have to know what your capabilities are. At the level I wasworking, I had to be able to envision how the pieces were going to fittogether. I had to have some intuition for what things were fast and whatthings were slow, what things were hard to build, what things were easy tobuild, and come up with, at the engineering level, a model of what I thoughtwas going to happen.

The artist part decides that the design should be elegant. Those fit togetherbecause in computer programs the artistry affects the longevity of it. Part ofwhat I call the artistry of the computer program is how easy it is for futurepeople to be able to change it without breaking it. That doesn’t haveanything to do with constructing its functionality but with its life as anexisting thing.

Seibel: So for you the beauty of code is tied up with the fact that peopleare going to have to change it.

Cosell: One or two things I wrote were black boxes that just had to run aslong as the computer cycled, but most of them were code that generationsof people were able to hammer on and mostly not keep breaking. When Italk about the artistry and the beauty of it, what I’m talking about is the ideathat when you write a program you have a huge amount of discretion. Howyou organize your routines, how you lay them out on the page, where youdecide to put comments, how you name your variables, whether you likeyour subroutines to all have uniform calling sequences or situational appropriatecode.

So you have to look at the program through the eyes of a new programmersometime down the road. What’s the structure of the program? What areyou doing? How are you doing it? And why are you doing it? The artistry ishow the next guy that reads the program and understands that thissubroutine was supposed to do this—he gets the message that it’s not rightfor him to go and muck it up to do something else and that he should keepthe structure of the program.

Seibel: What about the tension between clarity and efficiency? Sometimesthe simplest, easiest-to-read code isn’t the fastest.

Cosell: Programmers are the worst optimizers in the world. They alwaysoptimize the part of the code that’s most interesting to optimize, andalmost never get the part of the code that actually needs optimization. Soyou get these little nuts of very difficult code that have no point. I always tellthe people working with me, “Code it as lucidly, as easy to read, as crystalclearas you can. Do it the simple way. And then if it needs to be sped up,we’ll deal with that later. If you’ve done it right, we can draw a little boxaround this piece.”

Eons ago one of the versions of Emacs had one page of the source code thatwas a gigantic skull and crossbones in comments that said something like:“Seriously twisted code follows this thing.” It was some piece of theinnermost guts of the search code or something like that that they hadoptimized the hell out of. That’s a place where I can see that this piece isreally tough. So there’s a big black box around it saying, “Don’t stray inhere, unless you know what you’re doing.”

But programs we write these days are bigger and clumsier, in terms of theelegance I learned when I was doing PDP-1, and slower. And that’s fine. Itturns out it doesn’t matter. Now, the guys doing video synthesis and theguys doing the CGI animation stuff, clearly those guys don’t have thatluxury. That takes some beaucoup careful programming. I could not do thatanymore; I am way over the hill for that. But I could do that once. And Iunderstand the guys that do that. But most of the programs we do are justroutine crap.

At some college they had a two-semester course from September rightthrough May and you had you work on some fairly hard program at thebeginning. What they didn’t warn you was in April they were going to makeyou work on the program again, having now really run you through thehoops on other things. The idea was for you to be stunned at how hard itwas to remember whatever it was you thought you understood perfectlyclearly just six months ago.

Seibel: So all that stuff that you did at the last weekend before it was duecomes back to haunt you.

Cosell: That’s right. I thought that was a brilliant scheme. It’s teaching thema lesson that is hard to get except in the real world.

Seibel: When I talked to Ken Thompson I asked him about whether therewere inherent problems in C that lead to security problems and he basicallysaid that’s not the problem. You teach courses on computer security—whatdo you think of that?

Cosell: I would hate to cross swords with him, but I say in my computersecurityclass that the biggest security problem to befall modern computersis C. It was designed to be a systems-programming language and it was sucha comfortable systems-programming language that all the hotshots used it.We built operating systems out of it. We built real-time systems out of it.