Recently I received a preview copy of Peter Seibel's newest book, Coders at Work.
This is a wonderful book if you are a programmer and care at all about the art, craft, and/or science of programming. If there is any wisdom to be had in this fledgling field of ours, this book contains buckets of it.
The book consists entirely of long interviews with some big names in the world of programming: Donald Knuth, Ken Thompson, Jamie Zawinski, Guy Steele, Peter Norvig, the list goes on. There are also some names I wasn't quite so familiar with (but maybe should have been), like Brad Fitzpatrick, the inventor of Livejournal.
But everyone interviewed for the book has produced some grand, successful project in their time. These are tried-and-true, battle-tested programmers and in this book they share their war stories and advice.
Questions and Answers
There are a few questions that Seibel asked everyone, and it's interesting to compare and contrast the answers.
How do you start learning to program? Perhaps because of the varying ages of the interviewees, the answers range from punch cards to Perl scripts. Is a CS degree a necessity, a boon, or a hindrance? Is a background in mathematics necessary? Very different views depending who you ask.
How does a person become an outstanding programmer? Is the ability to program something you're born with or something you learn? This book has a lot to say on the topic, directly and indirectly. Knuth thinks that in any group of 100 people, "2 of them are programmers in the sense that they really resonate with the machine". Fran Allen says that working on a farm helped her have a better understanding of large complex systems with inputs and outputs. Many stories point to people being "naturals", e.g. Guy Steele learning APL from a couple brochures at an exhibit. But it's clear that years (or decades) of hard work and dedication are needed too.
If there's anything most of the coders have in common, it's starting at a young age and being rabidly enthusiastic. You get the impression that these guys (and gal) love programming. It's not just a job, it's a passion. Many are the tales of 26-hour coding sessions. Most of those interviewed say they still fiddle around with code in their spare time, even those who have retired from professional programming (or burned out on it entirely).
What tools do great programmers use? Which editors? Debuggers? IDEs? If this book is any indication, the answer is Emacs. Or in some cases, plain old pen and paper. There are a few representatives of the IDE side of the aisle, but mostly the tools are simple and the minds do most of the heavy lifting. (There's nary a mention of Vim. It breaks my heart a little.)
How do you go about debugging code? Print statements are (perhaps surprisingly?) very popular among the greats in this book. There is much lamenting over the current state of debuggers, which are, in the words of Brendan Eich, "pieces of shit from the '70s like GDB". One of the most common methods of debugging is just mentally stepping through code until you see a problem. Some of those interviewed share some of their horror stories of extremely difficult bugs to squash.
Is programming an art, a craft, a science, a kind of engineering, or something else? The answers are wide and varied; many seem to view it somewhere between an art and a craft, but some have other views. L. Peter Deutsch muses that "coder" is to software development what "bricklayer" is to constructing buildings.
A recurring theme in the book is the beauty of simplicity.
Many people interviewed for this book did their best work decades ago, when computers were very different beasts. Programmers were constrained by the technology of the times, but perhaps because of those constraints, code had to be simple and straightforward, and there was an elegance in that simplicity that we've since lost.
As a young programmer who never experienced such an environment, I found it enlightening to hear the opinions of those who had. Seibel asked everyone what they thought of today's world, and the answer was often amazement combined with fear and dismay.
Quoth Guy Steele:
I guess to me the biggest change is that nowadays you can't possibly know everything that's going on in the computer. There are things that are absolutely out of your control because it's impossible to know everything about all the software. Back in the '70s a computer had only 4,000 words of memory. It was possible to do a core dump and inspect every word to see if it was what you expected. It was reasonable to read the source listings of the operating system and see how that worked.
Knuth has this to say:
There's this overemphasis on reusable software where you never get to open up the box and see what's inside the box. It's nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what's inside the box.
Joe Armstrong, of Erlang fame:
Also, I think today we're kind of overburdened by choice. I mean, I just had Fortran. I don't think we even had shell scripts. We just had batch files so you could run things, a compiler, and Fortran. And assembler possibly, if you really needed it. So there wasn't this agony of choice. Being a young programmer today must be awful--you can choose 20 different programming languages, dozens of framework and operating systems and you're paralyzed by choice. There was no paralysis of choice then. You just start doing it because the decision as to which language and things is just made--there's no thinking about what you should do, you just go and do it.
And Bernie Cosell, one of the original programmers who worked on ARPANET:
At one level I'm thinking, "This is way cool that you can do that." The other level, the programmer in me is saying, "Jesus, I'm glad that this wasn't around when I was a programmer." I could never have written all this code to do this stuff. How do these guys do that? There must be a generation of programmers way better than what I was when I was a programmer. I'm glad I can have a little bit of repute as having once been a good programmer without having to actually demonstrate it anymore, because I don't think I could.
Dealing with the ever-increasing complexity of computers today is something we all struggle with. We're endlessly re-inventing wheels in this field; everyone knows it. Getting back to the basics is a very appealing sentiment.
The questions and answers in this book are brutally honest and buzzword-free, which is refreshing. It's enlightening and at times giggle-worthy. There's a kind of snark that only a disgruntled computer programmer can produce.
L. Peter Deutsch:
[M]y description of Perl is something that looks like it came out of the wrong end of a dog.
After college I worked for two years, for a software company in Cambridge. And after two years I said, "It took me four years to get sick of school and only two years to get sick of work, maybe I like school twice as much."
If I could change one thing -- this is going to sound stupid -- but if I could go back in time and change one thing, I might try to interest some early preliterate people in not using their thumbs when they count. It could have been the standard, and it would have made a whole lot of things easier in the modern era. On the other hand, we have learned a lot from the struggle with the incompatibility of base-ten with powers of two.
The only complaint I have about the book (if it is a complaint) is the length of the some of the interviews. Some were hard to get through in a sitting. There's also some profanity, if you care about such things (I don't).
If you buy this book expecting to hear stories about TDD and .NET and RoR and other such trendy three-letter acronymns, you may be disappointed. If you are immersed in the present and don't care about the past, this book may not be for you.
This book is a great read, educational and entertaining and I dare say inspiring. Other reviews have said this and I agree: Seibel is a programmer and he asks the questions a programmer would ask. I highly recommend this book. It's for sale mid-September; check the book's website.