Book Review: Coders at Work by Peter Seibel

Of the 15 names in the list I recognised just 7, so I can’t claim to have a great knowledge of great programmers. But that just seeing Donald Knuth on the list made me want to read the book. And having read it, I recommend it to you.

( amazon.co.uk | amazon.com )

The interviews share questions so you get a common feel for how the interview subjects all learned their trade. But the interviews flow as conversations with Peter Seibel injecting the common questions as appropriate for the person.

All interview subjects pass on ‘pragmatic’ views rather than PC mainstream views, and most of them started developing these views when developers worked closer to the metal and software had fewer lines of code, sometimes in languages we barely remember.

I find reading interviews interesting but slow work, so it took me quite a long time to finish this book, despite reading a pre-release copy, I didn’t manage to get a review out until well after the book’s publication date.

I originally wrote a longer review, peppered with quotes and a serial walk through of all the interviewees, but you can do that when you read the book. Instead I have pared it back to summarise some of the things that came across strongly from the book for me:

• work at your craft constantly,
• read code to learn from other people,
• write readable code – in some cases literate programming
• keep thing simple,
• build code, to ship products
• build incrementally and functionally to learn quickly
• do not over-engineer
• keep learning “If you don’t understand how something works, ask someone who does.”
• Use your app and have it running all the time.
• Good programmers program for fun outside of work - not just during work
• Think in subsets of languages and libraries – learn those subsets thoroughly and understand their limitations – use them based on appropriateness, complexity, applicability, and how well it lets you communicate
• Ship it – re-factor it
• Use static analysis
• Hire for smarts and practical ability rather than random and abstract problem solving
• Simplify

I also learned a few tips about naming conventions and commenting to allow scanning of code to pick up errors e.g. customerName and customerNames would instead have names like customerName and listOfCustomerNames to allow human reading/scanning to see the difference.

The various interviewees have strong opinions about programming languages, but I don’t remember any of them having found their perfect language.

Very few of them seemed to use IDEs, which suggests that they had in-depth and detailed knowledge of the language they coded in, and the libraries they used. Certainly, I use IDEs because I do not have that level of knowledge.

Automated testing doesn’t get covered very often by the interviewees, and those that do mention it cover it pragmatically – using it to automate the ‘clever’ code to guard against people changing it without understanding it.

Many of these programmers thought of themselves as writers – hence the emphasis on readable code and reading other’s code.

When not programming these people spend their time learning about and thinking about programming. The 10,000 hours to expertise comes through strongly in these interviews and they act as mentoring sessions. All of the interviewees have taken apart frameworks and other people’s code to see how it works, they have all worked closely with other very good people so had many opportunities to learn. Even if you think the people you work with do not have the ‘greatness’ you desire to learn from then you could pick the code from open source projects to read - but you have probably underestimated some of the people you work with.

For me, as a tester – an old programmer, but not as great as I used to consider myself. The fact that all these very strong developers talk about simplicity, readability, writing. Makes me feel better about my programming skills and gives me hope that by identifying subsets of the languages that I use well, I can still write good code.

“Coders At Work” links well with the notions presented in Kent Beck’s “Implementation Patterns”. And based on these two books I have subtly changed my approach to coding and now read more code.

Recommended reading for both developers and testers.

Related Reading:

• buy book and read reviews at amazon.co.uk
• buy book and read reviews at amazon.com
• Official homepage with profiles of all interviewees
• Peter Seibel’s blog – has useful follow up blog posts expanding on the book’s content
• Review of Masterminds of programming
• Joel on software review
• The code for http://www.jslint.com/ – mentioned in the interviews
• http://code.google.com/p/google-guice/ – mentioned in the interviews
• Kent Beck Implementation Patterns http://www.infoq.com/interviews/beck-implementation-patterns