Coders at Work: Reflections on the Craft of Programming

by Peter Seibel

Seibel: Have you ever found that code that was, at that level, a mess, then you cleaned it all up and discovered it was actually good code underneath? Crockford: I've never actually seen that. I think it's really difficult to write good code in a sloppy manner. By good code, I mean it's going to be readable. At one level, it doesn't matter what it does to a machine if I can't figure out what it does, so it might turn out that the code is amazing in terms of its efficiency, or its compactness, or some other metric which I don't care about. Readability of code is now my first priority. It's more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct. So I think it's probably not good code and they probably made the wrong trade-offs if the code turned out to be in the state that it's not easily readable.

Programmers are optimistic. And we have to be because if we weren't optimists we couldn't do this work. Which is why we fall prey to things like second systems, why we can't schedule our projects, why this stuff is so hard.

Keeping it all in your head is important.

Eich:

Software is a discipline of detail, and that is a deep, horrendous fundamental problem with software. Until we understand how to conceptualize and organize software in a way that we don't have to think about how every little piece interacts with every other piece, things are not going to get a whole lot better. And we're very far from being there.

As I built larger and larger systems, I found that when sitting down to write any piece of code, more and more the question I would ask myself first is, “OK, what's the interface between this and everything around it going to look like? What gets passed in? What gets passed out? How much of a task should be on which side of an interface?” Those kinds of questions started to become a larger and larger part of what I was dealing with.

Deutsch

I thought they were very good programmers, good designers. But they were not system thinkers. Not only were they not used to thinking in terms of the impact or ramifications of changes; they to some extent didn't even realize that that was an essential question to ask. To me the distinction is between people who understand what the questions are that you have to ask in doing larger-scale design and the people who for whatever reason don't see those questions as well.

Deutsch

Allen: I always start with interviewing anybody for IBM Research by trying to find out what they're excited about. That's kind of a basic threshold for me. And it doesn't matter whether it has anything to do with programming or computers. If they can't get enthusiastic about something, they're not going to get charged up in a group.

The third big challenge was simply how do you debug the thing. All of a sudden, you can't talk to Cincinnati, Ohio. What went wrong? How do you figure it out? You call Cincinnati, Ohio, and you get a sleepy night watchman at 3:00 in the morning walking up to this little blinking box in the corner. What does he look at? What do you do? And even if you get the system back up, what went wrong? How do you fix it? Remember, I was a big things-don't-crash, things-are-going to-keep-working guy.

Cosell

A lot of the times, just understanding what the bug is points you at the right piece of code. Now you read it more critically and you fix it. Other times, you need to collect more data. Other times, you need to bang your head against the wall trying to catch that little bit of evidence that illuminates the thing. And we did some of all of that.

Cossel

There was a level of trust and confidence that the three of us were going to do this thing and he left us alone. In retrospect, having been a project manager, that's a stunning thing; that's just bizarre. No weekly staff meetings, no PERT charts on the board. Willy was of course keeping track of what needed to be done and bugs we found and stuff, but the lack of oversight structure for that was pretty impressive. Throwing us together and telling us to go do it was, I think, a stroke of management bravery.

Cossel

That takes enough confidence in your skill as an engineer, to say, “Well that's wonderful. Here's my problem. I couldn't figure out how to do this and I was hoping you guys wouldn't notice so you'd give me an OK on the design review.” The implicit answer was, “Of course you're going to get an OK on the design review because it looks OK. Let's fix that problem while we've got all the good guys here so you don't flounder with it for another week or two.”

Cossel

there are very few inherently hard programs. If you're looking at a piece of code and it looks very hard—if you can't understand what this thing is supposed to be doing—that's almost always an indication that it was poorly thought through. At that point you don't roll up your sleeves and try to fix the code; you take a step back and think it through again. When you've thought it through enough, you'll find out that it's easy.

Cossel

The other rule is to realize that programs are meant to be read.

Cossel

They'd be stunned when I tell them, “I don't care that the program works. The fact that you're working here at all means that I expect you to be able to write programs that work. Writing programs that work is a skilled craft and you're good at it. Now, you have to learn how to program.” Some of these guys were fabulously good programmers and they'd never once read a line of anybody else's code. In fact, some of them never even read their own code, so they never had the pain of seeing what happens six months later.

Cossel

I try very hard to hide the crap, to move the crap someplace so that I can follow the flow of the code, so I can build the picture in my head of what the code is doing.

Cossel

Cosell: That's right. The path I took was, if you will, not for the faint at heart. At the time I was 19 years old and that seemed like the only way to do things. I had two convictions, which actually served me well: that programs ought to make sense and there are very, very few inherently hard problems. Anything that looks really hard or tricky is probably more the product of the programmer not fully understanding what they needed to do and pounding it with a hammer 'til they got code that looked like it did the right thing.

Cossel

When you finish with a routine I want every routine you work on to look as if it was just written. I do not want to see any evidence of afterthoughts or things gone wrong followed by something to correct the error or a mysterious piece of code saying, “This routine returns the wrong value every now and then so I've got to fix it.” I don't want to see any of that. I want to see code that looks like through some divine inspiration you got it exactly right the first time.

Cossel

I do a design of the future version of the program. Knowing what I know now, this is how the program would have looked, now at the program level rather than at a subroutine level. Now when you go to fix a bug and you have a choice on how to fix it, fix it moving toward the better model. Don't just fix it in the shortest way. Don't just fix it in the way that fits, but move it toward the other model so that over several months instead of the program getting more and more mired in patches fixing up the stuff that was old and wrong, all the critical parts of the program all of a sudden look like they're the new way of doing things.

Cossel

I always tell the people working with me, “Code it as lucidly, as easy to read, as crystal-clear as 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 box around this piece.”

Cosell

of the things I learned was how much software occupies the brain. It was a much more difficult task than I expected. I couldn't teach classes full-time and write software full-time. I could teach classes full-time and write a book full-time but software required so much attention to detail. It filled that much of my brain to the exclusion of other stuff.

Knuth

I have for reading original sources. Not just knowing that so-and-so gets credit for doing something, but looking back and seeing what that person said in his own words. I think it's a tremendous way to improve your own skills. It's very important to be able to get inside of somebody else's way of thinking, to decode their vocabulary, their notation. If you can understand something about the way they thought and the way they made a discovery, then that helps you make your own discoveries.

Knuth