Coders at Work: Reflections on the Craft of Programming 1st ed. Edition

I really like this book for the feeling that these people who have accomplished so much are just like me and do not do anything insane to achieve what they have. Many of their stories are like my own.

Sometimes we take the leaders of an industry and blow their importance and worth out of proportion: "Only THEY could have done it." That doesn't make their accomplishment any lesser and I like that this book shows the humanity that hides behind code and products they've built.

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

This book is just a bunch of interviews with some programmers you might recognize and some you may not. It seems to be pretty lightly edited and some people may find some sections boring (and others may not)! "Coders at Work" is a fascinating insight into the education, careers and minds of some pretty big names in the field. I ordered the book before reading some of the negative reviews and I'm very glad I did. I almost hesitated to start reading it thinking that it was going to be boring and dry but it wasn't. Yes, there is definitely heavy use of acronyms and terms that I wasn't familiar with but to me it was a learning opportunity and a chance to dig a little deeper to figure out what the interviewees were talking about.

It's tough to predict if this book will appeal to you. If you're a seasoned software industry professional with a deep love for the 'craft' of coding then you'll love this collection if interviews. I certainly did and it reminded me of why I got into this industry in the first place and it rekindled a love for coding.

*Spoiler*: The last bit of the last sentence of the last interview in this book is "don't only read the people who code like you."

At least one reviewer has complained that this title didn't "detail" how these programmers worked and how they approached programming. I must thoroughly disagree. The opinions of these people on common points of disagreement from type systems to tools and coding styles to debugging methods was explored. If you are hoping that you will be able to watch the subjects solve a complex problem or go through a typical day's work than you are in the wrong place. This isn't a screencast or a tutorial. On the other hand, there are a wide variety of opinions on display from experts in different areas of the field across different generations on numerous contentious issues.

This book is filled with words worth chewing on. On the first read, the interviews of Crockford, Deutsch, Eich, and Peyton-Jones stuck out to me in particular. In subsequent readings I expect that set to be different. All of the interviewees did agree on the importance of one thing, reading and writing code. For a beginner, this book is likely to point out some pitfalls that otherwise would've been missed and suggests valuable sources of intuition and insight. Perhaps most importantly, it may help popularize some knowledge of the history of our field. As Knuth laments, "The idea that people knew a thing or two in the '70s is strange to a lot of young programmers." There is some valuable distilled experience and wisdom here. At the very least, the book should help you hash over your own opinions on the issues discussed.