Coders at Work

I just finished reading Coders at Work, by Peter Seibel, and it was awesome. The book is a collection of interviews with some of the most respected and well-known programmers of our time. These are Turing Award winners, inventors of languages and operating systems that have touched millions of people, and authors of the most widely known and respected computer science literature you can find.

I kept a list of notes as I read through the book, things that resonated with my own years of experience in the field. There isn't any particular theme here, but I wanted to capture these ideas before they got away from me.

Working programs are a given

Bernie Cosell, who helped develop Arpanet (predecessor of the Internet), made a great point about the responsibilities of a professional programmer:

You don't get credit because the program works. We're going to the next level. Working programs are a given.

What he's saying is that when you work as a programmer, you job isn't done just because the program works. You need to generate something of high quality that you and your coworkers will understand six months from now, and which can evolve as the customer's requirements change. Professional musicians don't just play the notes, race car drivers don't just drive around the course, and serious programmers shouldn't be content with an ugly program just because it works.

Magic is dangerous

Guy Steele had a great way to sum up why programming is hard:

[Being] able to get a machine to do what you want is the closest thing we've got in technology to adolescent wish-fulfillment. And if you look at the fairy tales, people want to be able to just think in their minds about what they want, wave their hands, and it happens. And of course the fairy tales are full of cautionary tales where you forgot to cover the edge case and then something bad happens.

For example, take the story of King Midas, who wished that everything he touched would turn to gold; when granted in its most literal sense, this wish became a terrible curse.

Unfortunately for programmers, computers are the epitome of the fickle genie, interpreting us at our most literal and wreaking havoc when we don't clearly specify what we want. Therefore, as programmers our job is to provide such excruciatingly detailed instructions that the computer can't possibly misinterpret us and do the wrong thing. This can be one of the most frustrating things to communicate to non-programmers; it's not magic, and translating a simple idea into code is far from mechanical.

Microsoft's tools are awesome

Say what you want about Microsoft, but their developer tools are world-class. Most of the interviewees in this book come from the non-Microsoft parts of the programming world, and often bemoaned the lack of good quality debugging tools. In fact, it sounds like many of them do their debugging with little more than print statements. This is one of the oldest and most basic forms of debugging, and it has its place, but to paraphrase one of my favorite Despair posters, just because you've always done it that way doesn't mean there isn't a better way. A good interactive debugger is worth its weight in gold for a lot of problems, and I'm glad to be working with one of the best there is: Microsoft's Visual Studio.

Names matter. A lot.

Programs are nominally a set of instructions for the computer to follow, but they also have to be understood by humans who come along later and want to understand or change things. A program whose code can't be understood is in fact nearly useless, like a book written in a forgotten language.

One of the most crucial elements of legibility is using good names for things. If you write a procedure that flushes program data to the hard drive, and you call it FlushDataToDisk, a reader can immediately understand the basic purpose of the function, and might be able to skip reading all of the gory details of how it works. On the other hand, if you call it WriteStuff, the name tells the reader nearly nothing, and forces her to read the whole thing to discern its purpose. The problem is that when you're writing the code it's easy to just use the first name that comes to mind, without considering the impact that choice may have a few months or years later.

I've only recently started to take this issue so seriously, but given how many programmers in this book seem to feel the same way, I think I'm on the right track. I now regularly consult a dictionary and thesaurus as I write, and you should too.