Programming Books, part 1: Coders at Work

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 [,].  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:

  • With only one or two exceptions, these people seem very humble, quite unconvinced of their extraordinary ability.  Someone like Ken Thompson, who invented and programmed Unix with one hand while winning the world computer chess championship with the other and inventing UTF-8 with a third hand that he kept lying around for emergencies, comes across as just happy to be hacking and all-round unimpressed by his achievements.  (I once heard him give a talk on computer chess: he described one of the years in which he won the world championship simply as “a mistake”.)
  • None of the programmers seemed to have any time at all for formal design methodologies like UML.  While everyone recognised the value of informally whiteboarding ideas before ploughing into coding, there’s an overwhelming sense from these people that they prefer to start with only a broad design, and then refine as they code, discovering the details of the problem as they go.
  • No-one likes C++.  It seems to be regarded as, at best, a noble attempt to graft two incompatible worlds together.  Andrew Rilstone, in his review of Ang Lee’s film Hulk, memorably described it as “The whole thing doesn’t quite work, but it’s the sort of failure one would like to see rather more of”.  The impression you get of C++ from Coders at Work is that it was a success, but the sort of success one would like to see less of.
  • No-one is very excited about Java, either.  The general impression is of a grudging acceptance: that it does sort of get the job done, provided you don’t mind writing programs where two thirds of the code is workarounds for things the language itself doesn’t do.  The only actual enthusiasm for Java came from Joshua Bloch … whose job as Chief Java Architect at Google might just have circumscribed what he felt able to say.  (I will have more to say about Java in future entries.)
  • Lots of the interviewees were interested in functional programming.  Not in a religious thou-shalt-not-evoke-side-effects way, but as a practical tool to have in the kit.  One of the effects of this has been to make me think, again, that it really is time that I got properly to grips with Lisp (or, specifically, Scheme, which everyone agrees is the purest, and therefore the most Lispish, Lisp).  A few of the programmers were more rigorous about referential transparency, but they were the ones who needed it for parallelising computions.
  • Most people don’t bother with debuggers (GDB and the like), preferring to debug using low-tech approaches like the insertion of printf()s.  I was surprised by this, although I’d read something similar in Kernighan and Pike’s (1999) The Practice of Programming.  As a matter of fact, that’s how I do most of my own debugging, but I’d always felt that it was a bit of a guilty secret and that I really should invest more effort into learning debuggers.  It’s nice to know that I am at least in good company.
  • Everyone spoke highly of Knuth’s The Art of Computer Programming, and plenty of people owned copies that they dipped into from time to time, but only one person had actually read it all the way through.  (I don’t remember who, sorry).
  • Everyone agrees that Knuth’s “literate programming” seemed like a pretty neat idea, but no-one had ever actually done it.  (Er, except Knuth.)

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.

About these ads

29 responses to “Programming Books, part 1: Coders at Work

  1. Dennis Schafroth

    Published in 1972, could it be “The C Programming Language” by Ken and Dennis?

  2. Good guess, Dennis, but no — The C Programming Language was a relative latecomer, published only in 1978. Still, I will give you half a point.

  3. “Structured Programming” : Dijkstra, Dahl?

    My first guess was “The C Programming Language” as well.

  4. The AHU algorithms book? It’s still one of my favorites.

  5. Good guesses, but no … I’ve written the post about the 1974 book I had in mind, and will probably post it tomorrow. Stay tuned!

  6. I enjoyed this post! What refreshing thinking. Although I’m only a hobbyist programmer, I can somehow relate, and the book is going onto my wishlist right now.

  7. Pingback: Programming Books, part 2: The Elements of Programming Style « The Reinvigorated Programmer

  8. Well, Volume 1 of Knuth’s The Art of Computer Programming, Fundamental Algorithms, was first published in 1968. To me, as a professional software engineer, those 3 volumes are the Bible of the domain.

  9. “Everyone agree that Knuth’s “literate programming” seemed like a pretty neat idea, but no-one had ever actually done it. (Er, except Knuth.)”

    Well, Matt Pharr and Greg Humphreys did it in Physically Based Rendering (

  10. I strongly recommend that you learn Lisp, not Scheme if you want to understand the appeal of the language. Scheme is a stripped down subset designed for teaching certain elements of program structure. Lisp is an actual programming language and contains a great deal more.

    Both languages have closures, garbage collection and a similar set of data types, but Lisp has a number of other important elements.

    For example, Lisp code is plastic. The source language may be text, but the input to the compiler (and interpreter) is list structure. This means that the programmer can do code transformation and use it as part of system design. Need a specialized code construct, just write a suitable macro. Properly used, this can make your code much more readable. You design your problem solving language, then implement it using macros. The output is interpreter and compiler ready.

    There are lots of other features in Lisp that make it more of a complete language than Scheme. Sure, learn Scheme and read SICP, but Scheme is a distillaion of Lisp, not a substitute.

  11. Kaleberg, thanks for this advice. I’d understood that Scheme IS Lisp; just a specific, and rather spartan, dialect of Lisp compared with some others, such as Common Lisp. Not so?

    In any case, I’m struggling to figure out which specific Lisp and/or Scheme to learn — there are so many choices. Looking the packages supported by my O/S alone (Ubuntu 8.10), I see:

    clisp – GNU CLISP, a Common Lisp implementation
    cmucl – The CMUCL lisp compiler and development system
    drscheme – PLT Scheme Programming Environment
    ecl – Embeddable Common-Lisp: has an interpreter and can compile to C
    mit-scheme – MIT/GNU Scheme development environment
    sbcl – A Common Lisp compiler and development system
    scheme48 – A simple, modular, and lightweight Scheme implementation
    sigscheme – A Scheme Interpreter
    tinyscheme – Very small scheme implementation
    (and quite possibly others that I am missing.)

    And of course there’s Emacs Lisp, which is appealing in that I am already very comfortable with Emacs. Any suggestions?

  12. Scheme is a dialect of Lisp, but it has stripped down for pedagogical purposes. If you want to study control and access structure, you can’t do better than to pick a Scheme and pick up SICP and learn an awful lot while having a surprising amount of fun. I’ve used MIT Scheme. I worked on a port to the BB&N 256 processor Butterfly back in the 80s. It’s portable and open source. I’ve tinkered with PLT Scheme which isn’t bad either. I’m guessing that they are different branches of the original MIT code. A lot depends on what you think of the user interface. There was good EMACS / Scheme integration (^Xe to execute Scheme in a shell buffer).

    On the other hand. If you want a production language, I’ll recommend Common Lisp. CLISP worked pretty well. When I used it, KCL (Kyoto) was a bit clunky. To be honest, I did most of my Lisp programming before Common Lisp. I used the old PDP-10 ITS version at the MIT AI Lab. One guy there had a wall full of pennies, one for each major implementation upgrade. I wrote a tiny Lisp for a group at MIT, and my first user was a high school band guy who wanted to do computer animation. He won an Oscar for his work on flocking and schooling. He’s the only guy I know who ever won an Oscar. I also worked with Zeta-Lisp, the Symbolics version, which had a proto-Common Lisp typing system along with what a lot of Lisp purists called too many libraries.

    Scheme is a magnificent teaching tool, but Common Lisp is for building systems. It has an easier to use package system for namespaces. It has a full object system with inheritance, mix-ins, methods and so on. It has more advanced data structures. It has Lisp’s macro capabilities which are extremely important since they let you mold the language to the program’s semantic space.

    I haven’t used all that much, except for the EMACS version, for years. The original EMACS Lisp was an implementation of EMACS for Multics and it was written completely in Lisp. Things like save-excursion were built as Lisp macros. On the other hand, it looks like some of the implementations I remember are still around.

    Good luck in your new adventure. Lisp is worth it. (Paul Graham wasn’t just full of it.)

  13. Inform 7 ( is also written in a “literate programming” form of C, in addition to being a literate programming tool itself.

  14. I have been writing commercial software for 30 years, ranging from accounting software to real-time embedded safety-critical systems, to large-scale distributed enterprise manufacturing execution software.

    1. I love C++. It’s power to express and implement complex abstractions for robust system software is unparalleled, IMO.
    2. I also love UML, although I have had my toe-to-toe encounters with the likes of Grady Booch, et al over major and minor disagreements about semantics. Some of the stuff I have developed would not have been feasible without some sort of formal modeling tools. At the very least it helps one fully cognate on what you are trying to accomplish. The more complex the problem, the more useful formal tools become.

  15. I love Java. Lots of people love Java.

    Lots of the most exciting projects in software are happening in Java: Cassandra, Hadoop, Lucene. And these are research-like projects created by super passionate super knowledgeable guys who picked Java on purpose.

    Lots of staff at Google love Java and they use it in various projects.

    Even things like Ruby on Rails were obviously heavily influenced by Java MVC web frameworks and test-centric development tools.

    I could go on and on. Some parts of Java are crufty: JSF is awful. The maze of libraries to do something simple like logging can be completely unnecessary chaos. I never liked J2EE or Hibernate or JPA either.

    But, Java is easily the most exciting dev platform for me. It’s a great language, a great VM, has great Win/Mac/Linux OS support, and the richest development community. It’s still just a language/VM system… It’s nothing magical. But I really think you are off the mark when you say no one is excited about it.

  16. Mass, while I take your point that there are people out there who genuinely love Java, I found this part of your comment unintentionally revealing: “Even things like Ruby on Rails were obviously heavily influenced by Java MVC web frameworks and test-centric development tools.” It’s a typically Javacentric perspective to assume that Rails’s use of MVC is taken from the Java world, when in fact MVC long predates that language, having been described by Trygve Reenskaug in the 1970s. It may not be true of you personally, but my experience is that Java people are often Java-only people, and don’t see far beyond the boundaries of their gated community. I don’t think that’s a healthy place to be.

  17. To me, Java is C++ on training wheels… :-) Some of the systems I have designed would not have been possible without language support for multiple inheritance for example, and how java forces you to code interface class functions into each concrete class that inherits from the interface class is just a major PITA! Some sort of default behavior for an interface would be genuinely useful.

    As for platform independence, I haven’t had any problems with that issue when using C++ in a rational way. I’ve been developing systems and frameworks in C++ for almost 20 years that ported without difficulty to pretty much every OS known that had a decent C++ compiler. Of course, I’ve uncovered a number of bugs in those compilers (mostly the proprietary ones) that had to be fixed. We had to “rap the knuckles” of the VPs of Engineering at HP, DEC, and Sun in the past to get them fixed PDQ, but once they decided that dealing with the problem was easier than another phone call from me, the fixes were available within days.

    In any case, some code that is entirely dependent upon specifics of processor architecture has to be implemented differently to deal with those specifics. In such a case, it is likely that you would have to use some JNI interfaces to C functions for those since it is difficult to deal with machine-level dependencies in Java.

  18. Have you ever read “Programmers at Work” [ISBN: 0914845713]? “Coders at Work” almost seems to be an update to the former; maybe related is a better word for it. But from what everybody says I need to check it out.

    Oh, another interesting (and possibly related) book is “Show Stopper!” [ISBN: 0029356717] by G. Pascal Zachary who followed the Windows NT development team for Windows NT from conception to delivery. Intriguing and riveting.

  19. MVC as a concept is definitely much older than Java. David Heinemeier Hansson, the creator of Rails, mentioned Java and Java web frameworks repeatedly as the reason he made Rails. I’m not a historian, but it seemed to me that that style of web MVC framework was definitely popularized in the Java space with frameworks such as Struts (which is clearly cludgy compared to more current MVC frameworks like Rails, Django, Stripes, and ASP.NET MVC)

    I’ve worked as a full-time programmer for fifteen years and almost none of that was Java beyond small maintenance tasks and after hours hobby projects. Maybe that’s why I like it so much :)

    “my experience is that Java people are often Java-only people, and don’t see far beyond the boundaries of their gated community”

    You see some of that in every platform. I’ve worked in 100% Microsoft oriented companies for the last ten years, and know tons of Microsoft-only people who’ve never heard of anything that’s not a Microsoft promoted tool. And I see tons of the same type of closed-minded superiority in Ruby circles.

    “the classic Java-world attitude of flat-out rejecting anything that’s not written in Java.”

    Isn’t the premeire Java version-control-system, Mercurial, written in Python? Hasn’t Java very aggressive about supporting and integrating with every other language and platform? Lots of non-Java PHP/Python programmers that I know swear by NetBeans as the best IDE. Doesn’t the JVM have a vibrant support for community developed languages (Scala, Clojure, etc) and libraries?

    Your laments on the current state of API-gluing programming careers is pure briliance.

    However, your anti-Java sentiment is every bit as “gated” and closed-minded as the stodgy Java culture that you dislike.

  20. I’d never even heard of Programmers at Work at the time I published my Coders review, which is a bit odd — you’d have thought that Peter Siebel would at least have mentioned the older book in the newer one. But anyway, I ordered a second-hand copy two days ago, and I’ll probably cover it here at some point.

    I think I’ll skip the NT book, though: I am not a big NT fan, to put it mildly, and knowing how much it cost people to make it isn’t going to make me happy.

  21. OK, Mass, I am not going to continue to argue this :-)

    I will just say, though, that my “anti-Java sentiment” hasn’t stopped me from working on Java projects or releasing open-source Java code — see

  22. Regarding “Show Stopper!”, sorry if my point about it was unclear. It’s not so much a reading of the internals of Windows NT; there are plenty of other books about that.

    What made the book interesting to me was the behind the scenes story of the project and the developers themselves. How it impacted their professional and personal lives, the technical obstacles they had to overcome, and the politics (the breakaway from IBM & OS/2, grafting the Windows 3.x GUI onto it, etc.)

    One part that’s always stood out in my mind is the developer that was so overcome by the project that he broke down and started spending his cubicle days finding ways to win at Windows Solitaire.

    It’s just a good, overall read on what goes into a major development project that many of us will never have the chance to experience – for good or bad.

  23. ok, you win. Thanks!

  24. Pingback: The long-overdue serious attempt at Lisp, part 1: which Lisp? « The Reinvigorated Programmer

  25. Pingback: The long-overdue serious attempt at Lisp, part 2: is Lisp just too hard? « The Reinvigorated Programmer

  26. Pingback: Are you one of the 10% of programmers who can write a binary search? « The Reinvigorated Programmer

  27. Pingback: Git is a Harrier Jump Jet. And not in a good way « The Reinvigorated Programmer

  28. Pingback: Steve Jobs “never had any designs. He has not designed a single project” | The Reinvigorated Programmer

  29. Pingback: Programming Books, part 5: Programming Pearls | The Reinvigorated Programmer

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s