Clean Coder
Yesterday I finished reading The Clean Coder: A Code of Conduct for Professional Programmers (affiliate link) by Robert C. Martin. In this book, Uncle Bob expose his view of what it is to be a professional programmer. The author have been programming for 40 years and he have very strong opinion about the subject of professionalism in programming.
The Book
In the first chapter he defines professionalism in our career. A lot of it turns around taking responsibility for our actions. He also compare our profession to being a doctor by saying that we should Do no harm. We should strive not to harm the function and the structure of our programs. He then describes the means by which we should ensure that we don’t hurt our code. Those means are the subject of the rest of the book.
The following two chapters are about how we answer requests. The importance of saying no, and of delivering when we say yes. We should never accept to commit to something we can’t deliver. But when we commit to something, we need to make sure we deliver it. Uncle Bob publish a great story taken from the blog of John Blanco that is really worth reading. It’s a great example of how bad it can get when we fail to say no. John also has a great recipe for manipulating developers. Tell them the the app is simple, add features by faulting them for not seeing their necessity and push the deadline to get them to do more. Reading it made me realize that I have seen it in action many times. And I had fell for this trick myself.
He then follow about the actual act of coding. How we should prepare to code. The importance of being rested and free of worries. He takes a stand against “the zone” talks about how we should be more forgiving of interruptions. He also speaks about the importance of helping others and being helped by others.
The next chapter is about Test driven development. This is something I try to practice more and more. I already wrote a post about it.
He then move on practicing. He describes Code Kata and coding dojo. He also talks about how to get more experience by contributing to open source projects.
The next two chapters are about testing. He speaks about acceptance tests. How they should define the requirements and make the definition of done pretty clear. These tests should always be automated and should run pretty quickly. He then describes the testing strategies. The most important thing to remember, is that QA should not find anything. He list the different kinds of tests and their goals.
In chapter 9 and 10, the author speaks about time. How to manage it and how to estimate projects. He mentions meetings, how they can be important, but also useless. We should try to be in the important one, and use the Law of Two Feet when we end up in the others. He also mention The Pomodoro Technique and avoiding getting caught in blind alleys and messes. Then he mention a few techniques for estimating tasks.
Chapter 11 is about pressure. How to avoid it, and how to mitigate it. Developers are often under a lot of pressure. Some of it we cause to ourselves by not saying no when we should. Some of it is caused by the importance of our work for our employers. Learning how to handle this pressure is important.
The following two chapters are about working with others. In chapter 12, the author speaks about collaboration. How important it is for us to collaborate with other developers, but also with other peoples. Then chapter 13 is about teams and projects. He describes the importance of having a good team that works well together.
Chapter 12 is about mentoring, apprenticeship and craftsmanship. He describes how valuable mentoring can be. A mentor can help bring a junior developer up to speed, but it also can help the mentor get a better understanding of what he has to teach. The author then describes an apprenticeship model where developers would start as an apprentice before moving to being a journeyman and finally a master.
The books ends with an appendix on the tools the author uses. He mentions source control, testing tools, editors, issue tracking and continuous integration servers.
My Take On All Of This
The Clean Coder is a very good book. Uncle Bob have a very strong opinion on how software should be developed. I don’t agree with everything he says, but in general he makes good points.
One of the interesting things about the book is that it is full of stories taken from the career of the author. He show us how to become better developers by showing us some of his failures. Seeing how and why he failed can help us avoid some of these mistakes.
I wish I had this book earlier in my career, but I’m not sure I will have understand it’s importance. It his a great handbook on improving as developers. And it’s a great reminder of how far I still need to go if I want to consider myself a professional developer.