Uncle Bob Martin’s eagerly awaited sequel to Clean Code, cleverly named The Clean Coder, is a powerful argument for professionalism in software development. People who’ll benefit from this book the most are programmers at the start of their careers or those who are burned out and work with software and companies plagued by technical and organisational issues. The book has a lot of sound advice to offer, in particular around commitment, planning and estimation, personal ethics and collaboration, as well as an overview of techniques such as TDD, pair programming, and automated acceptance testing.

The gist of the book is, for me, captured in the following quotes:

  • You can’t take pride and honour in something that you can’t be held accountable for
  • QA should find nothing
  • The true professional knows that delivering function at the expense of structure is a fool’s errand.
  • Woe to the software developer who entrusts his career to his employer.
  • Professionals speak truth to power. Professionals have the courage to say no to their managers.

Those who don’t suffer that much from poor team or software will not benefit that much from The Clean Coder, but there are a few gems in for them as well. I found the argument against flow (or “The Zone”) particularly interesting, as I’ve never looked at the topic in the way described in the book. References to probability based estimation were also interesting, as well as explanations of some more exotic time management strategies. Most importantly, through many interesting war stories, we as readers get to peek into Uncle Bob’s experience and learn from his mistakes.

If I was picky and had to choose a few negative things to say, I’d probably point out the start of the book as unnecessarily off-putting and negative. It paints a picture with a clear adversarial relationship between programmers and management or clients, which doesn’t really match my background or current situation. Sure there have been a few bad apples in my project basket, but the picture painted was a bit too negative for my taste. On the other hand, people who need to hear the message of this book will probably identify with that dark painting of their reality. I’ve also never been good at reading books with lots of invented dialogue, something in my reading circuits makes me skip invented conversations. This made it hard to follow the flow of thoughts in some parts of the book but it has more to do with my attention deficit and reading skills than the book itself.

So to conclude, this book is not going to replace the Pragmatic Programmer as my favourite “you have to read this first” suggestion to new members of our profession, but it deserves to be on that list.