the onda

Coders at Work is a fantastic book worth reading for anyone who does software development. Like the old classic, Programmers at Work, it takes you on tour inside the heads of some of real giants in the field of software development including Dan Ingalls, Ken Thompson, Donald Knuth, and a guy who was previously unknown to me but who gives the most thought-provoking interview in the book, L. Peter Deutsch.

Peter Seibel, the author of the book, does a tremendous job interviewing these guys. It sort of makes you wonder whether the combination of the Internet (with its "email me your questions and I'll shoot you something back" interview style) and made-for-Youtube video interviews (with their constant attempts at generating soundbites) have destroyed the art of good interviewing (maybe Peter ought to do a sequel, "Interviewers at Work.")

There are plenty of really interesting technical nuggets delivered by what in the case of the folks in their 50s, 60s, and 70s, I think is the last generation of software engineers who truly understood the whole enchilada top-to-bottom, from how the chip behaves in great detail to the user interface and developer APIs. But what struck me most about the personalities in the book was how many of them thought that people in the field today (which is remarkably young by the standards of most branches of engineering) don't pay enough attention to prior art. This comes up again and again— in fact I've heard Alan Kay bemoan this very fact on the couple of occasions I've gotten to see him live.

And yet when Seibel asks some of these luminaries why they've become disillusioned with software as a whole, a common theme emerges that it's no longer interesting because the systems have become too large and layered for them to be able to make fully understood and self-contained contributions they were used to making earlier in their careers. One definitely gets the feeling that back in those days, had there been more prior art, these guys might have also blithely ignored it for the sake of whatever implementation was consuming them at the time.

The book is long, but well worth the time invested in reading it, if only to remind you just how incredibly insightful a really good software engineer can be.