New Book Review: "Coders at Work"

New book review for Coders at Work: Reflections on the Craft of Programming, by Peter Seibel, Apress, 2009, reposted here:

Despite the title, which uses the term "coder" to describe the software developer, this 600-page series of 15 interviews by Seibel is actually quite fascinating. In the words of the author, the questions he posed to these accomplished software developers are varied, revolving around "how they learned to do it, what they've discovered along the way, and what they think about its future". While these were some of the questions asked of all interviewees, like any good journalist Seibel used these as starter questions, going on unique tangents for each along the way. This reviewer noticed that several readers had expected some type of how-to guide by each individual interviewed, but the content here is composed of discussion points, as the subtitle suggests. If you enjoy interviews in the software space, such as those that one might regularly find on InfoQ, you will probably enjoy this collection.

Though weighty, there are numerous great sound bites throughout. Jamie Zawinski, "one of the prime movers behind mozilla.org, the organization that took the Netscape browser open source", is quoted as saying "I hope I don't sound like I'm saying, 'Testing is for chumps.' It's not. It's a matter of priorities. Are you trying to write good software or are you trying to be done by next week? You can't do both. One of the jokes we made at Netscape a lot was, 'We're absolutely 100 percent committed to quality. We're going to ship the highest-quality product we can on March 31st." Seibel poses the following question to Douglas Crockford, inventor of JSON: "In one of your talks you quoted Exodus 23:10 and 11: 'And six years thou shalt sow thy land, and shalt gather in the fruits thereof: But the seventh year thou shalt let it rest and lie still' and suggested that every seventh sprint should be spent cleaning up code. What is the right time frame for that?" To which Crockford replies: "Six cycles – whatever the cycle is between when you ship something. If you're on a monthly delivery cycle then I think every half year you should skip a cycle and just spend time cleaning the code up."

Brendan Eich, creator of JavaScript, later comments: "Abstraction is powerful. What I'm really allergic to, and what I had a bad reaction to in the '90s, was all the CORBA, COM, DCOM, object-oriented nonsense. Every startup of the day had some crazy thing that would take 200,000 method calls to start up and print 'hello, world'. That's a travesty; you don't want to be a programmer associated with that sort of thing. At SGI, the kernel, of course, was where the real programmers with chest hair went, and there you couldn't screw around. Kernel malloc was a new thing; we still used fixed-sized tables, and we panicked when we filled them up. Staying close to the metal was my way of keeping honest and avoiding the bulls***, but now, you know, with time and better, faster hardware and an evolutionary winnowing process of good abstractions versus bad, I think people can operate above that level and not know assembly and still be good programmers and write tight code."

Joshua Bloch, Chief Java Architect at Google at the time this book was written, comments that "there's this problem, which is, programming is so much of an intellectual meritocracy and often these people are the smartest people in the organization; therefore they figure they should be allowed to make all the decisions. But merely the fact that they're the smartest people in the organization doesn't mean they should be making all the decisions, because intelligence is not a scalar quantity; it's a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn't be designing APIs or GUIs or languages. What we're doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills – all of these things that we don't necessarily think of as engineering but without which I don't think you'll ever be a really good engineer."

Summarized as the "mother" of Smalltalk (the counterpart to Alan Kay, the "father" of Smalltalk), Dan Ingalls comments that "people should learn to think clearly and to question. And to me it's very basic. If you grow up in a family where when the cupboard door doesn't close right, somebody opens it up and looks at the hinge and sees that a screw is loose and therefore it's hanging this way vs. if they say, 'Oh, the door doesn't work right; call somebody' – there's a difference there. To me you don't need any involvement with computers to have that experience of what you see isn't right, what do you do? Inquire. Look. And then if you see the problem, how do you fix it? To me it's so basic and human and comes so much from parent to child. Computers are certainly a medium for doing that. But they're just computers. There's a lot of that that will transfer, but to me it's really big and basic and human, so it's not like we're going to enlighten the world just by teaching them computers."