Author: Robert C. Martin
Publisher: Prentice Hall
Pages: 256
ISBN: 978-0137081073
Aimed at: Aspiring professional programmers
Rating: 4.5
Pros: Amusing anecdotes and sound advice
Cons: No code!
Reviewed by: Harry Fairhead

Billed as "a code of conduct for professional programmers" what does "Uncle Bob" have to offer?

This is a book with a lot of preliminary material starting with an extended dedication. Then comes a Foreword by Matthew Heusser which is anecdotal but gives a context for the book. Next is a Preface about the Challenger Space Shuttle disaster and how the engineers who suspected there was a risk posed by the O-Rings were overruled by managers who were under financial and political pressure. This is followed by five pages of acknowledgements. About the Author occupies little more than a page and introduces Robert Martin's (aka "Uncle Bob")") as the founder of Object Mentor Inc and also of Uncle Bob Consulting and author of many well regarded books. The final and oddest inclusion in the preamble of this slim book is two pages devoted to an explanation of its cover photo - a composite of visible and x-ray light captured using both the Hubble and Chandra telescopes of the Crab Nebula pointing out the bright blue dot at its center where the pulsar is - without any clue as to why this very lovely image was chosen!

When finally we get to pages numbered with arabic rather than roman numerals, we are faced with a section headed Pre-Requisite Introduction which we are advised not to skip. This is a short account of the author’s first steps as a programmer - a story of compiling (or rather failing to compile) punch cards, being fired, working to a hellish deadline for low pay, quitting without another job to go to, and eating humble pie to be rehired for an even lower salary. It includes an anecdote (the one illustrated in the cartoon at the beginning of the chapter) about inserting updates into a huge ring-bound IBM manual including pages bearing only the legend "This page intentionally left blank". Today's new programmer may be tempted to ask "documentation - what's that?"

The last sentence of the introduction is:

So think of this book as a catalog of my errors, a blotter of my own crimes, and a set of guidelines for you to avoid walking in my early shoes.

The Introduction sets the tone for the rest of the book – it’s anecdotal and chapters are introduced with cartoons, some linked to quotes from a variety of sources. The one for Chapter 1 is taken from The Treasure of the Sierra Madre and depicts a hillbilly or ol' timer - which doesn't seem to fit with its topic of Professionalism!

The anecdote, under the heading taking responsibility, is a however very apt and is about shipping a new release of code written in assembler without fully testing it in order to ship on time and not lose face. The untested routine failed, customers lost data and were angry but Martin learned the lesson that software should not ship until fully tested. The next part of the chapter explores the idea that the first responsibility of a software developer is to "do no harm" and the chapter concludes with a section on Work Ethic. Some of the advice may not seem palatable - for example:

You should plan on working 60 hours a week. The first 40 are for your employer. The remaining 20 are for you.

- to spend reading, practicing, learning including such things as listening to podcasts on your commute. And of course reading any of the material on this site including this this review would count!

Chapter 2 is called Saying no and addition to several scripts illustrating exchanges between project managers and programmers it uses a third-party experience from an app developer to explore the cost of saying yes. Saying Yes is the title of Chapter 3 and is about the language of commitment.

Chapter 4: Coding describes the authors personal set of rules and principles for the activity of coding - not the code itself but about behavior while writing code. The author discusses preparedness, the Flow Zone, which he advises you to avoid, writer's block and debugging. In the section on Pacing Yourself there's advice to walk away and take a break:

"When you are tired, disengage for a while".

Yes we all know the wisdom of that. So often after hours sitting in front of a monitor all it takes in 10 minutes of a run or a shower (an activity that Martin also suggests) for an elusive bug to reveal itself.

The next chapter is a short one on Test Driven Development - a discipline Robert Martin learned from Kent Beck who was using a thirty-second cycle time with a Java program. The chapter introduces FITNESSE a Java-based acceptance testing tool of which Martin is primary author and maintainer.

Chapter 6: Practicing returns to the idea that the professional programmer spends a proportion of time on self-improvement. It offers some ideas for skill-sharpening exercises including coding dojos where coders get together to work on a programming challenge.

The next two chapters cover acceptance testing and QA testing respectively and are prefaced by a discussion of communication with other members of a team and with stakeholders. The ideal is that the by using Test Driven Development at the QA stage there should no bugs left to find.

Chapter 9: Time Management has a lot of ideas to offer for cramming as much productive work as possible into an 8-hour day – from declining to attend meetings, holding stand-up meetings and using the Pomodoro Technique. Next comes an equally practical chapter on estimation with the insight that:

Business likes to view estimates as commitments. Developers like to view estimates as guesses. The difference is profound.

Again there’s a personal anecdote to motivate the discussion but unusually statistical notation is included in examining PERT (Program Evaluation and Review Technique). Anecdote also introduce the topics of the following two chapters on pressure – how to avoid it and how to cope with it – and collaboration – how to work with other programmers. In both these chapters pair programming is advocated. Then Chapter 13: Teams and Projects explains that as teams require time to gel it is best to keep the same team together over as many projects as possible.

The final chapter, Mentoring, Apprenticeship and Craftsmanship, is both entertaining and challenging. First we have the story of a computer science graduate who can’t write code and then Martin looks back to how he learned to program (at age 12) using a Digi-Comp 1. He concludes the chapter by saying that while school can teach the theory of programming it is up to the software industry to teach the discipline, practice and skill of being a craftsman and that a program of apprenticeship, internship and long-term guidance is required.

The book rounds out with a useful appendix A Tooling on what to have in your toolkit. There's a comparison (using code from FITNESSE) of Subversion and Git with the conclusion that Git is the preferred source control system. Martin also uses Tracker for issue management, Jenkins for continuous build, IntelliJ as his IDE, XUnit for testing and FITNESSE for component testing.

I enjoyed this book partly because I have stories of my own that came to mind while reading it. It has good advice for the next generation of developers and for those who are taking on the roles of team leaders or project managers. It is recommended reading for anybody aspiring to be a professional programmer.