Book Review - The Clean Coder

Book: The Clean Coder - A Code of Conduct For Professional Programmers

Summary Of Content Read

This book is largely a follow-up to Martin's other very well known book "Clean Code". Whereas that book focuses on the artifacts (code) we developers produce this book focuses on the developer his/herself. How should we as professional developers act? What is the difference between a commitment and estimate? What are our responsibilities? When can we say no & how do we do it? When are we obligated to say yes? How do we get better at what we do?

Martin tries to distill his nearly 40 years of experience into some hard fought lessons. While it is very much appreciated to hear "tales from the trenches", the book does have a fairly heavy-handed "do as I say" tone. Don't do TDD? Well then you're not a professional. Do you create ambitious estimates? Well then, you're not a professional. From a rhetorical point of view, the book does rely on this "proof by appeal to professionalism" approach, rather than give solid evidence and data to back up many of the arguments he makes. For example, the TDD chapter has the passage:

Yes there have been lots of controversial blogs and articles written about TDD over the years and there still are. In the early days they were serious attempts at critique and understanding. Nowadays, however, they are just rants. The bottom line is that TDD works, and everybody needs to get over it.

I feel like the paragraph should have ended with "QED". Hardly a conclusive argument in favour of TDD, and the off-hand dismissal of any critiques of the practice really does hurt the point he's making.

Having said all this, it is certainly clear that much of what he offers is good advice, and represents an open challenge to developers to be better. If you put aside the "if you don't do this you're not professional" rhetoric, at its core this book is a call for developers to live up to the responsibility of the job they have been hired to do. Oftentimes we as developers like to silo ourselves off, focus on our narrowly defined technical tasks, and that is simply unrealistic. Part of the responsibility of being a developer is to understand the context of the work you do, why it's important and why it adds value to the customer/client/business/etc. And if that value isn't there, it's up to you to find it.

As such I found this book both refreshing and terrifying. Refreshing to hear a voice from the agile community who doesn't seem to feel that the PO is the only entity responsible for identifying value.
Terrifying to think that I, as an introverted software developer, has a duty to do more than just simply write good, clean code.

In terms of structure, the book is divided into 14 different chapters each covering a topic of interest to professional developers. While there is some technical discussion, it is relatively rare, by in large the chapter topics focus on "soft" skills rather than technical ones.

All-in-all, while heavy-handed and at times "preachy", it is very much a worthwhile read for anyone considering or living a career in software development.