The Reinvigorated Programmer

Programming Books, part 1: Coders at Work

Advertisements

For some reason, I seem to learn better from books — actual, printed books — than I do from other forms of documentation.  You’d think that programming of all things would be best learned at a keyboard, web tutorial in one window and shell in the next, but somehow when I need to absorb a big chunk of information in one go, books work better for me.  I suppose they are more isolating, and encourage more concentration.

Anyway, books have been very important in my development as a programmer, and I want to talk on this blog about some of those important books.  As I write this, I have eight books in mind, though I may well think of others as I gradually make my way through these.

Most of the books on my list are quite old (one of them from 1974, which I think is the oldest).  That’s not accidental — I think that, even in as fast-moving a discipline as programming, it takes time for a book to establish itself as a classic; and the really good books are timeless.  So there will be no Learn Head-Rush Turbo Enterprise Java Enterprise Beans For Dummies In The Enterprise In Twenty Minutes in this series.  (Bonus points, by the way, for anyone who can guess what the 1974 book on my list is.)

But although I love old books, I want to start this series with the most recent book on my list (although as you’ll see the 2009 publication date is in some ways misleading, as it’s largely about programs written long ago).  That’s because it’s the book I’m reading right now — I’m in the middle of the last chapter as I write this — and it’s the book that probably did more than anything else to provoke me to start this blog.

Coders at Work: Reflections on the Craft of Programming -- Peter Siebel

The book is Coders at Work: Reflections on the Craft of Programming, by Peter Siebel [amazon.com, amazon.co.uk].  It’s a series of lengthy, rambing interviews, averaging forty pages each, with fifteen programmers.  These include some seriously big hitters: among others, Jamie Zawinsky, Peter Norvig, Guy L. Steele, my own hero Ken Thompson, and finally — saved for the last chapter — Don Knuth.

Any one of the interviews taken alone is a fascinating read; but where the book really scores is that as you read one, then another, then another, all sorts of patterns start emerging.  As you’d expect, there is little in the way of unanimity — how could there be with something as personal as programming? — but there is a lot of commonality between these programmers, whose careers span from the 1950s to the present day.  Some of those themes:

Overall the impression was that these fifteen people — who, let the record show, have written shedloads of really important code that we all use every day — tended to be very pragmatic.  Ken Thompson’s dictum “When in doubt, use brute force”, while not explicitly quoted anywhere in the book as far as I recall, seems to be a sort of unstated undercurrent.  An old Internet acquaintance of mine was once on a how-to-write-a-novel mailing-list run by Tom Clancy.  Apparently his contribution was “Just write the damn book”.  It surprised me how often the fifteen subjects of Coders at Work seemed to be saying “Just write the damned program”.  Or at least “Think hard, then just write the damned program.”

Speaking of Ken Thompson, his slightly unguarded comments about C++ and Bjarne Stroustrup make interesting reading:

In an interview I said [that I didn’t use C++] just because it wouldn’t stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language. I never said it was a bad language. On and on and on. Since then I kind of avoid that kind of stuff.
[…]
It certainly has its good points. But by and large I think it’s a bad language. It does a lot of things half well and it’s just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it’s personal or corporate, selects a subset and these subsets are different. So it’s not a good language to transport an algorithm—to say, “I wrote it; here, take it.” It’s way too big, way too complex. And it’s obviously built by a committee.
Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said “no” to no one. He put every feature in that language that ever existed. It wasn’t cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that.

Peter Siebel summarises some of his interviewees’ thoughts on C++ on his own blog.  Shortish and well worth a read.  Also intereasting, if you want to sample the book before committing real, live money, is this selection of quotes.

Why is the book good?  (I’ll try to finish all my book-related articles by addressing this question.)  Because it offers a slice through time, covering more than half a century of programming.  While an amazing amount has changed in that time (plenty of the interviewees have experience with punch-cards, paper  tape and toggle-switches on a front-panel), a surprising amount has also stayed the same.  Seems to me that any insights into programming that are good across fifty years are carrying some real weight.

Advertisements