In 2007, Jessica Livingston wrote a book called Founders at Work, in which she interviewed a number of tech entrepeneurs about their experiences in the early days of their startups. I enjoyed that book very much, and so I was quite excited to see that Peter Seibel recently wrote what could be called the second part of what I hope will be a series of interview books. Instead of founders, this time it is all about programmers, and the title of the book is Coders at Work: Reflections on the Craft of Programming (released in late 2009).

Coders at Work consists of extensive interviews (each interview some 40 pages long) with 15 of the best-known programmers of the last 4 decades:

• Jamie Zawinski, author of XEmacs and the Unix version of Netscape Navigator.
• Brad Fitzpatrick, creator of LiveJournal, author of memcached.
• Douglas Crockford, creator of JSON.
• Brendan Eich, inventor of JavaScript.
• Joshua Bloch, author of the Java Collections Framework.
• Joe Armstrong, inventor of Erlang.
• Simon Peyton Jones, Co-creator of Haskell.
• Peter Norvig, Director of Research at Google.
• Guy Steele, Co-designer of Scheme.
• Dan Ingalls, principal creator of Smalltalk.
• L. Peter Deutsch, author of Ghostscript and implementor of Smalltalk-80.
• Ken Thompson, creator of Unix.
• Fran Allen, pioneer in optimizing compilers.
• Bernie Cosell, one of the guys who wrote the first routers (Interface Message Processors) for the Arpanet.
• Donald Knuth, über-father and creator of TeX.

The interviews follow the same broad structure: Peter Seibel asks everyone how they got into programming; how they learned it in the first place and how they perfected their skills; which programming languages they like and which they hate; which editors, IDEs and debugging tools they use; how they approach the design of a program, top-down or bottom-up; etc. In addition to the general questions, Seibel digs deep into the projects his subjects are famous for: How did they end up working on these projects? What was it like? How was the project team organized? What did you learn? What were the hardest problems to solve, the fiercest bugs to squash?

To me, the greatest insight came from the interviewees’ reflections on their craft: How do they think about themselves and how do they personally practice programming? Despite having quite different backgrounds, it was interesting to discover that many of them had a common philosophy when it came to approaching programming.

For example, many mentioned their desire to take things apart, to understand how stuff works, as one of the prime impulses that brought them into the field. Also, motivation is a very important factor for learning, and personal side projects were often the ones where they learned the most. On the question whether it made sense to write the umpteenth C compiler or image processing library instead of just taking one that is already available, Joe Armstrong said:

The really good programmers spend a lot of time programming. I haven’t seen very good programmers who don’t spend a lot of time programming. … And you get better at it—you get quicker at it. The side effect of writing all this other stuff [side projects] is that when you get to doing ordinary problems, you can do them very quickly.

The importance of reading and writing

When asked whether they, as programmers, think of themselves as scientists or engineers or artists or craftsmen, some said they felt most like a writer whose job is to formulate their thoughts so that their audience — which comprises both the computer and readers of the source code — understands them best. You want to become a great programmer? Write a lot of code! Jamie Zawinski:

It feels like you’re writing a story and you’re trying to express a concept to a very dumb person—the computer—who has a limited vocabulary.

Similarly, nearly everyone mentioned that reading code is as important as writing it. Many said that reading other people’s source code (written either by more-experienced co-workers or the code of well-known open source projects) was a formative experience for their development as a programmer. Still, it struck me that these experiences mostly came from accidental exposures to great pieces of code. Almost none of the 15 had made it a personal habit to explicitly grab the source of an interesting piece of software and read over it for both learning and fun. Or, as Joshua Bloch put it, When was the last time you sat down at night to read a beautiful piece of code?

Short of attacking monster projects like the Linux kernel, how do we find the good code that is worth reading, the code that makes us better programmers by studying it? I think there is a great opportunity for blogs and other websites here to research and present the truly great pieces of code in open source projects in an easy-to-digest and informative form. Perhaps Peter Seibel’s new project, Gigamonkeys Quarterly, could partly evolve into something like this.

Historical quality

One reviewer of the book on Amazon:

There is also a historical quality to the book. The majority of the people interviewed started programming in the 50s or the early 60s. One of the standard questions was “How did you learn to program?” and I thought it was quite interesting to read about the old computers they used, the punch cards etc. It was almost like little history lessons from the computing field. — Henrik Warne

While this is certainly true and nice, I felt that the book lacked a certain balance between the “old guys” and the young coders of today who learned programming on and for the Web. Brad Fitzpatrick is basically the only representative of the Web generation of programmers. I think including more of his generation could have given readers further insight on the learning and practice of programming today. This is especially so since many of the interviewees, having learned their craft decades ago, lamented the complexity of today’s hardware and software and how much harder it is today to dig deep into how things work at the most basic level. So how do people learn to program these days and how to they cope with the fact that they will never understand how the machine they are writing code for actually works? For instance, I would have liked to see David Heinemeier Hansson included in the book.

Wrap-up

If you want to learn more about Coders at Work, Peter Seibel talked about it on episode #69 of the Stack Overflow podcast. He also held a one-hour long speech at Google where he talks about a few anecdotes and some of the topics he addresses in the book.

I found Coders at Work entertaining and inspiring. Reading the book has provided me with long lists of more books I want to read and programming languages I want to learn. Highly recommended for programmers; not recommended for non-programmers who want to learn more about programmers and programming. Finally, my favorite quote from the book is by Peter Seibel himself:

Speaking of writing intricate code, I’ve noticed that people who are too smart, in a certain dimension anyway, make the worst code. Because they can actually fit the whole thing in their head they can write these great reams of spaghetti code.