Coders at work

December 5, 2010

Recently, I finished reading Peter Seibel’s Coders at Work. If you’re a programmer interested in the history and critique of your craft, here’s a book worth perusing. Coders at Work is a collection of fifteen interviews with some of the most “famous” or “interesting” programmers alive today. I wrap “famous” and “interesting” in scare quotes because they’re subjective terms at best – especially in as diverse a field as computing – so perhaps “programmers who have achieved renown whilst working on high-profile projects” is a more accurate description of those in question. For instance, though I’d only personally heard of at least seven of the book’s fifteen interviewees, of the seven, only three – Donald Knuth, Peter Norvig and L. Peter Deutsch – had I any significant acquaintance with their writings or work. Nevertheless, fame or fortune notwithstanding, those interviewed in the book are programmers with decades of wisdom and experience (well, except maybe Brad Fitzpatrick), and it’s certainly worth considering their stories, advice and opinions. At the very least, if only to learn what not to do. (Oh, and how painful it was to be a programmer in the days of punch cards.)

Because it’s a collection of transcribed interviews, there’s really no legitimate reason to read Coders at Work linearly from cover to cover. In fact, if you do pick up this book, I wouldn’t recommend doing so (though, ill-informed as I was, that’s exactly what I did). Instead, it’s probably best to cherry-pick chapters on a whim. The reason for this is simple: redundancy. One of the more interesting attributes of Coders at Work is also its greatest weakness: the astonishing consensus of opinion on a wide group of topics from such a diverse group of programmers. On issues as far ranging as a language design, job interview strategies, computer science books worth reading, code readability and formatting, debugging strategies, and how to classify programming as craftsmanship, science, engineering or art, there is remarkable similarity of response. While not all of the fifteen ever completely agree on anything — in fact, in some instances there’s quite polarized disagreement — generally the redundancy of advice and information renders itself simultaneously enlightening and tiresome.

Here’s a summary of what I gleaned to be the majority opinion on a few of the less-divisive topics:

  • Code is, first and foremost, for people to read. This is probably the most common assertion made by nearly every interviewee in the book, and it was heartening to hear if only because it reinforced my own beliefs on the matter. Good programmers have to be good writers, because programming is as much an act of communication as it is of problem solving. Anybody can write code that a computer can understand, but few can write code that is also easily comprehensible by another human. Write appropriate comments. Use well-named variables. Keep a thesaurus handy.
  • Puzzles in job interviews are generally worthless. This was another theme reiterated throughout the book. Forget the silly hoops that the folks at some large software shops — like Google and Microsoft — make all those poor fresh college grads jump through. It’s far better to get a sense of the interviewee’s programming style, personality, critical thinking skills, and aptitude for curiosity than to award a job based on his or her ability to solve some random puzzle. C++ is a bad language. Personally, I hate C++ and I was glad to hear that I was in good company with my distaste for the language. Almost nobody interviewed in Coders in Work had anything good to say about C++. Jamie Zawinski, for instance, called it an “abomination.” And even Ken Thompson described it as “a garbage heap of ideas that are mutually exclusive.” (Peter Seibel has a more thorough list of interview quotes on the design flaws and challenges of working with C++.)
  • If you’re going to get only one book on computer science or programming, get Donald Knuth’s The Art of Computer Programming. Knuth’s classic set of volumes was cited again and again as worth reading. Ironically, almost nobody had actually done that. And even fewer said that the math contained therein was truly worth the average developer’s time to trudge through. A bit contradictory, if you ask me. Yes, The Art of Computer Programming may not be the best choice for light weekend reading, but Knuth’s volumes on algorithms and data structures certainly are valuable reference material. And allowing them to collect dust on your shelves will make you look smart.
  • Programming is mostly a mix of craftsmanship and art. Most interviewees rejected the idea that science has much of a role to play in computer programming — or even computer science itself — and few were willing to use the term “engineering” when describing their work. Instead, they almost unanimously gravitated towards the word “craft.” Josh Bloch called it an “aesthetic pursuit.” The downplay of the role of “science” and “engineering” in day-to-day programming was quite humbling, and many interviewees seemed to have high levels of respect for those who engage in “real” science and engineering.

Of course, this is only the tip of the iceberg and Coders at Works covers much more than this. If anything, I’d say what I got most of the book was inspiration. Yes, the current state of modern software is disheartening. Yes, it’s too complex, too inflexible, too massive, too unreliable, too unfriendly, too riddled with bugs. But the field is young and there’s still hope. Here’s a group of people who have made significant contributions to solving these problems simply by following their passion. Maybe we can too.

But first things first: we need to stop calling ourselves “coders.”