Coders at Work

Book cover image

Although the idea of an interview book is so simple –go talk to a bunch of people good at what they do, and write down the interesting stuff they tell you– they somehow differ wildly in quality, the good ones being rather rare, and the bad ones being many and really bad. I guess this has to do with the importance of the connection between the interviewer and interviewees, and how the lack of such a connection causes the reader to cringe when thinking of how uncomfortable the interview situation must have been.

Due to this opinion of mine regarding interview books, I was a bit reluctant to read Coders at Work despite the good reviews. After reading it, though, and going through it again for this review, I have to say that Coders at Work is pretty far at the “good end” of the cringe-to-delight spectrum of interview books. The interviewees chosen by Seibel are among the best and most influential programmers one can find on earth today (although I would have wished more open source developers, like Torvalds or Guido van Rossum), and he does a great job of getting the individual wisdom out of each of them. This probably has to do with Seibel being a hacker himself who wrote a well-known book on Lisp, giving him developer street-cred, in addition to being a former journalist and writer. He also has his opinions about software, such as how developers are bound by accidents of history much more than they are boundby physical constraints (p.125), but he manages deftly to get people to talk about these issues, instead of arguing with them himself.

There are a number of topics Seibel questions everyone about. These are: How they debug (surprisingly many using printf) and design code, how they dive into a big code base, which editor they use (very glad as an Emacs user to read that except Crockford pretty much everyone uses Emacs), and whether they read Knuth’s Art of Computer Programming. Another topic Seibel asks everyone about is what they make of the theory vs. practice division in Computer Science, and whether they think CompSci research is relevant for the average programmer. The agreement here is unanimous on the academy being preoccupied mostly with the wrong topics (such as formal proofs, which all see as irrelevant to application development) and missing the really difficult topics which occupy programmers (such as concurrency).

Regarding some other topics, Seibel does not intentionally ask his subjects, but patterns and opinions emerge. One of these concerns testing; Zawinski provides the perspective of someone who had to ship a piece of software or otherwise see the company go to ruin, whereas Steele talks about how he had to start writing tests for his functional programming excursion, because there was no way to insert print statements. Another interesting perspective is how Joshua Bloch of concurrent Java fame and Simon Peyton-Jones (the inventor of Haskell) agree on the importance of invariants, but for different reasons; Bloch thinks it’s great to document what your code assumes, so that you can understand it later, whereas Peyton-Jones finds invariants a great way to start understanding a complicated program.

The people interviewed vary largely in age, which makes for an interesting contrast of programming experiences. While some of the developers could understand everything going on in the computers they programmed for (Ken Thompson, Guy Steele), others wrote software that ran on complicated platforms and had to deal with all kinds of other problems – which Steele admits is more difficult than what his generation faced. A similar historical perspective is offered by Douglas Crockford, who points out that what’s new in computer technology is not automatically progress; the timesharing systems people used to work on before the advent of the PC created a community where people could exchange all kinds of digital information. This sense of community was lost with the insular PCs, and not recovered until the advent of the Internet. Peter Deutsch similary argues that all the good ideas programming languages of today embody were already implemented in much older languages, although the tooling has become much better.

I think Coders at Work will be the first interview collection that I will keep around to have a peek into one of the interviews every now and then.