Coders at Work: Reflections on the Craft of Programming

by Peter Seibel

Speaking of pearls, Brian Hayes has a lovely chapter in this book Beautiful Code entitled, “Writing Programs for ‘The Book’” where I think by “The Book” he means a program that will have eternal beauty. You've got two points and a third point and you have to find which side of the line between the two points this third point is on. And several solutions don't work very well. But then there's a very simple solution that just does it right.

find the book

Systems are filled with so much goop—in order to build an ASP.NET web service-y thing you need to know about this API and this tool and you need to write in three different languages and you need to know about Silverlight and LINQ and you can go on doing acronyms forever. And each of them has a fat book that describes it. This is a tension I don't know how to resolve. These are useful systems—they're not designed by accident. Each of them is there for a reason and each of them has a smart person who's thinking hard about how this thing should be architected. But nevertheless, each, individually, has a broad interface. It may or may not be deep but it's certainly broad. There's a lot of stuff you need to just have in your head. It's like learning a language—a human language—there's a large vocabulary. For me, that's no fun. I never learned my multiplication tables. I always worked them out from first principles every time and I just developed enough tricks that I could do it quickly enough. When you do seven nines I still have to go, oh, seven nines, oh, seven tens and subtract, so it's sixty-three. Whereas other people just learnt them. And that's a relatively small thing. So I hate things were you just have to learn these big things. So instinctively I back away from these big goopy things. But at the same time I acknowledge that they're useful and important in practice. The question in my mind is, if you were able to take a bit longer to design some of these things, coul...

The most depressing thing about life as a programmer, I think, is if you're faced with a chunk of code that either someone else wrote or, worse still, you wrote yourself but you no longer dare to modify. That's depressing.

You've got to read some algorithm book. You can't just pick these things out and paste them together. It could be Knuth, or it could be the Cormen, Leiserson, and Rivest. And there are others. Sally Goldman's here now. She has a new book out that's a more practical take on algorithms. I think that's pretty interesting. So you need one of those.

It's also important to know what you're doing. When I wrote my Sudoku solver, some bloggers commented on that. They said, “Look at the contrast—here's Norvig's Sudoku thing and then there's this other guy,” whose name I've forgotten, one of these test-driven design gurus. He starts off and he says, “Well, I'm going to do Sudoku and I'm going to have this class and first thing I'm going to do is write a bunch of tests.” But then he never got anywhere. He had five different blog posts and in each one he wrote a little bit more and wrote lots of tests but he never got anything working because he didn't know how to solve the problem. I actually knew—from AI—that, well, there's this field of constraint propagation—I know how that works. There's this field of recursive search—I know how that works. And I could see, right from the start, you put these two together, and you could solve this Sudoku thing. He didn't know that so he was sort of blundering in the dark even though all his code “worked” because he had all these test cases. Then bloggers were arguing back and forth about what this means. I don't think it means much of anything—I think test-driven design is great. I do that a lot more than I used to do. But you can test all you want and if you don't know how to approach the problem, you're not going to get a solution.

Seibel: Why is it so tempting to solve a problem we don't really have? Norvig: You want to be clever and you want closure; you want to complete something and move on to something else. I think people are built to only handle a certain amount of stuff and you want to say, “This is completely done; I can put it out of my mind and then I can go on.” But you have to calculate, well, what's the return on investment for solving it completely? There's always this sort of S-shaped curve and by the time you get up to 80 or 90 percent completion, you're starting to get diminishing returns. There are 100 other things you could be doing that are just at the bottom of the curve where you get much better returns. And at some point you have to say, “Enough is enough, let's stop and go do something where we get a better return.”

Norvig: He understands the code perfectly. Other people can write code better but he understands all the implications of what goes where. Seibel: Do you think those are related? It often seems that people who write the worst spaghetti code are the ones who can hold the most in their head—that's the only way they could possibly write code like that. Norvig: Yeah, I think that may be.

my first tries at writing curried functions in Java and the spaghetti that came out of it

Now I'm less likely to use any book for reference—I'm just likely to do a search. Seibel: Just because it's more convenient? Norvig: It's convenient. I think it's also that I'm probably more goal-oriented. Knuth is good if you say, “I want to know everything about this subject.” But usually I'm saying, “I want to know if A is better than B,” or, “I want to know the asymptotic complexity of this, and once I've got that, I don't need all the details of how we got there.”

Steele: By the time I was applying to colleges I applied to MIT, Harvard, and Princeton and really wanted to go to MIT. I got accepted at all three.

sounds familiar, except the last part, i guess

Seibel: What code have you read most recently just for fun? Steele: It's hard to find good code that's worth reading. We haven't developed a body of accepted literature that says, “This is great code; everybody should read this.”

Seibel: As our languages get better, or at least more programmer-friendly, compared to the days of assembly language on punch cards, it seems like it's easier to write correct programs—you get a lot of help from compilers that flag errors for you and so forth. Is it possible to allow the focus on readability to come first, if only slightly ahead, of correctness? After all, as the Haskell folks are fond of saying, “If your Haskell program type checks, it can't go wrong.” Steele: I think that's a terrible pitfall. There are so many ways for a compilable program to have errors in it that you really do need to worry about correctness all the time. And if it's not correct you'll mislead not only the computer but your human readers, too.

I think it's not an accident that we often use the imagery of magic to describe programming. We speak of computing wizards and we think of things happening by magic or automagically. And I think that's because being able to get a machine to do what you want is the closest thing we've got in technology to adolescent wish-fulfillment.

Seibel: You also mentioned Knuth's TeX, which is obviously a much larger program. What is it that makes that program beautiful? Steele: He took a very, very complicated program with lots of special cases and reduced it to a single, very simple paradigm: sticking boxes and glue together. That was an immensely critical breakthrough. It turns out to be flexible not only for typesetting text but for all manner of other things as well that have to do with laying things out visually, two-dimensionally, on a page. I wish that more GUI interfaces were based on boxes and glue for laying out buttons and things like that.

Steele: Yeah. And not knowing the future. If I could change one thing—this is going to sound stupid—but if I could go back in time and change one thing, I might try to interest some early preliterate people in not using their thumbs when they count. It could have been the standard, and it would have made a whole lot of things easier in the modern era.

so 0-indexed counting?

Seibel: Seymour Papert wrote in Mindstorms about debugging as an important element of an intellectual toolkit—the idea that the name of the game is not to get the right answer but to get an answer and then debug it. Ingalls: Oh, absolutely! People should learn to think clearly and to question. And to me it's very basic. If you grow up in a family where when the cupboard door doesn't close right, somebody opens it up and looks at the hinge and sees that a screw is loose and therefore it's hanging this way vs. if they say, “Oh, the door doesn't work right; call somebody”—there's a difference there.

Seibel: Do you feel like there were times in your life where your passion for programming ran amok to the detriment of other parts of your life? Ingalls: Yeah, there are times when it's been hard on others because I'm focused and need to stay focused. It's a risk with anybody who's got a passion for what they're doing. I think either you learn to moderate it somewhat or the other thing you do is communicate it so that everybody around you knows that you're dealing with this thing, and you'll probably be done in a week, but until then Daddy's somewhat inaccessible.

Seibel: To say nothing of the scale. Two to the 64th of anything is a lot, and things happening billions of times a second is fast. Deutsch: But that doesn't bother us here in the real world. You know Avogadro's number, right? Ten to the 23rd? So, we're looking here around at a world that has incredible numbers of little things all clumped together and happening at the same time. It doesn't bother us because the world is such that you don't have to understand this table at a subatomic level. The physical properties of matter are such that 99.9 percent of the time you can understand it in aggregate. And everything you have to know about it, you can understand from dealing with it in aggregate. To a great extent, that is not true in the world of software. People keep trying to do modularization structures for software. And the state of that art has been improving over time, but it's still, in my opinion, very far away from the ease with which we look around and see things that have, whatever it is, 10 to the 23rd atoms in them, and it doesn't even faze us.

So responding to your question about whether the way I programmed in the small changed as I started to work with larger systems, the answer is, yes. 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. And they did affect the way that I wrote individual smaller chunks of code, I think.

Deutsch: No, I didn't. Well, OK, I do remember when I started rewriting the text editor on Dennis's PDP-1; I must have been 15 or 16. The original code had been written by one or two of the guys from the Tech Model Railroad Club group. Those were smart guys. And I looked at the code and I thought a lot of it was awful. I would not say it was a difference between me and the people I was working around. It was a difference between the way I thought code should be and the code that I saw in front of me. I would hesitate to generalize that into a statement about the people.

guess if I was to pick a short snappy phrase I would probably say software developer. That covers pretty much everything from architecture to coding. It doesn't cover some of the other things that have to happen in order to produce software that actually works and is useful, but it covers pretty much all of what I've done. Seibel: What doesn't it cover? Deutsch: It doesn't cover the process of understanding the problem domain and eliciting and understanding the requirements. It doesn't cover the process—at least not all of the process—of the kind of feedback loops from testing to what happens after the software has been released. Basically “software developer” refers to the world within the boundaries of the organization that's developing the software. It says very little about the connections between that organization and its customers or the rest of the world, which, after all, are what justifies the creation of software in the first place.

But that brings me to the other half, the other reason why I like Python syntax better, which is that Lisp is lexically pretty monotonous. Seibel: I think Larry Wall described it as a bowl of oatmeal with fingernail clippings in it. Deutsch: Well, my description of Perl is something that looks like it came out of the wrong end of a dog. I think Larry Wall has a lot of nerve talking about language design—Perl is an abomination as a language. But let's not go there.

lol

And I had this little epiphany that the reason that I was having trouble finding another software project to get excited about was not that I was having trouble finding a project. It was that I wasn't excited about software anymore. As crazy as it may seem now, a lot of my motivation for going into software in the first place was that I thought you could actually make the world a better place by doing it. I don't believe that anymore. Not really. Not in the same way. This little lightning flash happened and all of a sudden I had the feeling that the way—well, not the way to change the world for the better, but the way to contribute something to the world that might last more than a few years was to do music. That was the moment when I decided that I was going to take a deep breath and walk away from what I'd been doing for 50 years.

Seibel: Do you ever write down anything before you start writing code? Thompson: I usually write down data structures before I write down code. I don't write down algorithms—no flowcharts, or stuff like that. But the stuff you have to refer to on almost every line of code—data structures. Seibel: If you're writing a C program, does that mean C code that would define those data structures? Thompson: No, little boxes with arrows and stuff.

Documenting is an art as fine as programming. It's rare I find documentation at the level I like. Usually it's much, much finer-grained than need be. It contains a bunch of irrelevancies and dangling references that assume knowledge not there. Documenting is very, very hard; it's time-consuming. To do it right, you've got to do it like programming. You've got to deconstruct it, put it together in nice ways, rewrite it when it's wrong. People don't do that.

Seibel: How do you identify talented programmers? Thompson: It's just enthusiasm. You ask them what's the most interesting program they worked on. And then you get them to describe it and its algorithms and what's going on. If they can't withstand my questioning on their program, then they're not good. If I can attack them or find problems with their algorithms and their solutions and they can't defend it, being much more personally involved than I am, then no. At the same time you can get a sense of enthusiasm. It's not something you ask directly, but in the conversation you'll come with this enthusiasm-ometer, and that is tremendously helpful for me. That's how I interview. I've been told that it's devastating to be on the receiving side of that.

Recently I realized what was probably the root cause of this: computer science had emerged between 1960 and 1970. And it mostly came out of the engineering schools; some of it came from mathematics. And the engineering schools were mostly all men in that period. And the people IBM was hiring had to meet certain requirements: have certain degrees and have taken certain courses in computer science. And so they were almost all men because they were the ones that satisfied the requirements—because it was a discipline now.

I really believed that computers were deterministic, that you could understand what they were supposed to do, and that there was no excuse for computers not working, for things not functioning properly. In retrospect, I was surprisingly good at keeping the system running, putting in new 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 I was 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 to believe that very few computer programs are inherently difficult. I would take some piece of code that didn't look like it was working and I would try to read it. And if I could understand, then I could usually see what was wrong or poke around with it and fix it. But sometimes I would get a piece of code—often one that other people couldn't make work—and I would say, “This is way too complicated.” So I would think through what it was supposed to do, throw it away, and write it again from scratch. Some of the folks I worked with—like Will Crowther—who are terrific programmers, couldn't tolerate that. They would believe that by doing that, I would probably have fixed the 2 bugs that were 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 differently than the original programmer h...

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: Do you have any advice for the many programmers who are self-taught? 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.

I believed, as I likely still believe now, that anything I can understand, I can make a computer do.

Seibel: So I'm curious—I've observed that often the programmers that write the hairiest, most complicated code are the ones who can keep a ton of details in their mind. You obviously had the ability to keep details in your mind but still cared a lot about making code simple and clear. Cosell: I have to admit that I did both. I would make things simple in the large. But when I say that programs should be easy, it's not necessarily the case that specific pieces of the functionality of the program have to be easy. I could write some very complicated code to do the right thing, right there, code that people would cringe at and not be willing to touch. But it was always in an encapsulated place.

Another principle was I always wanted clean listings. I wanted the thing to be just right. When you have to fix a bug in a program you never, ever fix the bug in the place where you find it. My rule is, “If you knew then what you know now about the fact that this piece of code is broken, how would you have organized this piece of the routine?” What were you thinking about wrong before? Fix the code so that can't happen. 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.

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

Knuth: So you say advocate—it's sort of my shtick to say that this is good. But I also am the kind of guy that's uncomfortable preaching or trying to convert someone. I think programming is a lot like religion; people have their beliefs. Some people like to force their beliefs on others. Others say, you know, here's what I think; I can't prove that this is the best thing, but it sure works for me. Then you hope that other people will try it and come to the same conclusion. But I don't like going out and telling people what they ought to believe.

Knuth: The first rule of writing is to understand your audience—the better you know your reader the better you can write, of course. The second rule, for technical writing, is say everything twice in complementary ways so that the person who's reading it has a chance to put the ideas into his or her brain in ways that reinforce each other. So in technical writing usually there's redundancy. Things are said both formally and informally. Or you give a definition and then you say, “Therefore, such and such is true,” which you can only understand if you've understood the definition.

Seibel: Do you write literate code for programs that no one but you will ever see? Knuth: Exactly. This is what literate programming is so great for—I can talk to myself. I can read my program a year later and know exactly what I was thinking.

good git history might have the same benefits without documentation rot

But now I use change files all the time because I'm writing programs for myself that I'm using writing my book—I've got lots of problems that I want to solve and I want to experiment with different versions. Like yesterday I wanted to find out how big a Boolean circuit is for multiplication of n-bit numbers. I have a program that takes any Boolean function and finds out how big its BDD is. So I've got a program that takes any Boolean function and computes its BDD. In my original program you input the truth table of the function online—it says, “Give me a truth table,” and I type in a hexadecimal number, because I had a lot of small functions that I'm using as examples. But it only works for small functions, the ones that I want to type in the truth table. Then I've got a big function like, “Multiply all pairs of 8-bit numbers.” This is a function of 16 variables—there are 8 bits in x and 8 bits in y. So I write a little change file that takes out this interactive dialog and replaces it with a program that makes a truth table for multiplication. Then I changed that by saying, “Let's read the bits from right to left instead of from left to right, which gives you a different BDD.” Or, “Let me try all Boolean functions of six variables and I'll run through them all and find out which one has the largest BDD.” But all of these are customizations of my original thing. I'll have maybe 15 variants of that program that are easily understood. This was an unexpected spin-off from lit...

git and forks/short-lived branches improves on that idea, i think

I think what happens is that every time a new language comes out it cleans up what's understood about the old languages and then adds something new, experimental and so on, and nobody has ever come to the point where they have a new language and then they want to stop at what's understood. They're always wanting to push further. Maybe someday somebody will say, “No, I'm not going to be innovative; I'm just going to be clean and simple, and I'm going to stick to it.” Pascal was started with that philosophy but then didn't continue. Maybe we'll get to a time when somebody will say, “Let's set our sights lower and really try to make something that's going to be stable.” It might be a good idea.

go?

Seibel: I haven't really done a study, but it seems like the vast majority of mathematical and scientific papers are typeset with TeX these days. There must have been things you've seen typeset in TeX that made you think, “Wow, my program played a part in this.” Knuth: Well, the proof of Fermat's Last Theorem was one of those.

could it be interesting for a layman like me to check out

Even when I started writing my books in 1963, I didn't think people knew what had happened in 1959. I was reading in American Scientist last week about people who had rediscovered an algorithm that Boyer and Moore had discovered in 1980. It happens all the time that people don't realize the glorious history that we have. The idea that people knew a thing or two in the '70s is strange to a lot of young programmers. It's inevitable that in such a complicated field that people will be missing stuff. Hopefully with things like Wikipedia, achievements don't get forgotten the way they were before. But I wish I could also instill in more people the love that 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 was just basically the way you solve some kind of an unknown puzzle—make tables and charts and get a little more information here and make a hypothesis. In general when I'm reading a technical paper, it's the same challenge. I'm trying to get into the author's mind, trying to figure out what the concept is. The more you learn to read other people's stuff, the more able you are to invent your own in the future, it seems to me. We ought to publish code. The Lions Book is available. And Bill Atkinson's programs are now publicly available thanks to Apple, and it won't be too long before we'll be able to read that. That's well-documented code with lots of pioneering graphics algorithms in it. Seibel: Certainly with open source there's a lot more code out there to read than there used to be. Knuth: Yeah, that's right. But the more varieties of different kinds of notations are still useful—don't only read the people who code like you.