I just finished reading The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin.
Martin, affectionately known as “Uncle Bob” to many software professionals, is a well-known advocate of Agile development practices and software craftsmanship. A little more than a year ago my colleague Erik Rydeman recommended Martin’s Clean Code, and that book had a significant impact on my work.
Clean Coder (2011) is Martin’s most recent book. It’s a slim volume of lessons from his career, written so that others can learn from his mistakes. The book focuses less on code and more on the behavior of those who write it. I found this book less transformative then Clean Code, but it’s the best survey I’ve read of the real challenges faced by programmers at work, and I wish it had existed in 2009 so I could have read it as I finished my undergraduate degree. Here are my key takeaways today:
Commitment
It should be no surprise that four whole chapters are dedicated to making and keeping commitments: “Saying No,” “Saying Yes,” “Estimation,” and “Pressure” all deal with the challenge of telling management what you can and can’t do, and sticking to it. I liked one part in particular: Martin demonstrates that a clear language of commitment (I will do something by this time) and eliminating language that eschews responsibility will prevent many commitment problems. When you unequivocally take responsibility, you are less likely to overcommit – it makes you look bad! This may seem like obvious, generic advice for any discipline, but it’s necessary in software when we are often so bad at estimation, and often so pressured to throw our estimates.
Flow
I was surprised by a small tirade against the flow state many coders experience while working. Martin takes just a page to say that flow is harmful – that it trades in rational thought for a sense of speed and focus, and furthermore that flow makes a person irritable when interrupted and slow to resume their work.
I had a positive attitude toward flow until Martin pointed something out that changed my perspective: Pair programming blocks flow, because it encourages constant communication. The last few months at work are the first time I’ve spent the majority of my time pairing, and I haven’t missed the flow experience at all. Instead, I have written better code at a steady pace and been less bothered by interruptions than ever. For a team, anything that breaks down communication is a problem. I’ve changed my perspective on flow (and maybe on headphones) because of this observation.
Acceptance Testing
The one discipline discussed that I still have not used is acceptance testing. It’s tempting to write this chapter off, especially since Martin promotes his own tool, Fitnesse. But I’ve had positive experiences with the other disciplines in the book, so I’m anxious to give this a try. I’m not sure how useful a solo trial would be though – I may need to wait until I can convince a small team to give this a shot before I can evaluate its usefulness.
At the end of the book, Martin describes a simple system of software apprenticeship where engineers can be identified as masters, journeymen, and apprentices. At this point in my career, I seem to fit squarely into the journeyman category – five years of full-time employment writing software (skipping some non-programming schooling in the middle), experience on four shipped products all using different technologies, and becoming familiar with key disciplines. This book brought the inexperience of my past into painful focus (many thanks to the employers and colleagues that have pulled me through my apprenticeship years!). But it also gives me hope that I’m on the right track and points out new directions for growth.
I think this book has earned a permanent place on my shelf, just to skim every couple of years as a reminder of professional conduct.
