I develop web applications in Montreal. I work mostly with PHP, Javascript and MySQL. I try to learn as much as I can about everything that touches development, but there not enough hours in a day. Eric is a DZone MVB and is not an employee of DZone and has posted 8 posts at DZone. You can read more from them at their website. View Full User Profile

Clean Coder

07.07.2011
| 8328 views |
  • submit to reddit

Yesterday I finished reading The Clean Coder: A Code of Conduct for Professional Programmers 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 the 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 testing. 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 has an apprentice before moving to being a journeyman and finally a master.

The books then 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.

 

From http://erichogue.ca/2011/07/books/clean-coder/

Published at DZone with permission of Eric Hogue, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Mauro Jean-françois replied on Thu, 2011/07/07 - 2:19am

Thank you for this article. I appreciate that someone gives its opinion on such a good book.

Michal Huniewicz replied on Thu, 2011/07/07 - 4:35am

Thanks for the review, but is it too much to ask to have someone verifying published materials against basic English language rules?

Eric Hogue replied on Thu, 2011/07/07 - 7:01am

Thank you for you comments, I appreciate that you guys took the time to write them.

@Jean-François: Yes, it is a very good book.

@Michal: I'm sorry about the mistakes. English is my second language and I was tired when I published. But I should have been more careful. If you where kind enough to point some of the worst mistakes I made, I would make sure I don't make them again.

Michal Huniewicz replied on Thu, 2011/07/07 - 7:32am

Hi Eric, no worries, English isn't my first language either and I'm sure I make lots of mistakes, neither do I know where all the commas should go. So someone else should've looked at that.

First paragraph: exposes, has, has. :)

On another note, would you recommend the book to someone who has already read "Clean Code"?

Eric Hogue replied on Thu, 2011/07/07 - 8:16am in response to: Michal Huniewicz

Hi Michal,

Thanks for taking the time to answer. After your comment, I took the time to re-read my post and fixed a few mistakes. Unfortunately, I did it on my blog, so the fixes might not appear here.

As for having someone for DZone reviewing the text, the post was not written for them. They just take the post from my blog and reproduce it here as is (with my permission of course). So they are not responsible for any mistakes I make. You can look at the MVB Program, it's a great way to give visibility to your posts.

I've read Clean Code before, and yes I would recommend reading The Clean Coder also. The books have different focus. Clean Code is centered on the code, how to produce better code. The Clean Coder doesn't have a single line of code. It's centered on the developers and how he can get better. The notion of professionalism is everywhere in the book.

I think Clean Code, The Clean Coder and the PPP book are complementary books. They are look at our job from a different angle and are worth reading.

Michal Huniewicz replied on Thu, 2011/07/07 - 8:38am in response to: Eric Hogue

Gotta read it then. :) Thanks.

Alpar Gal replied on Wed, 2011/07/13 - 2:43pm

Hi Eric, Nice review. It's really worth reading and learning from this book. I agree with you. By the way this book was published at May 13, 2011 so you were not able to get it earlier than this, even if you wanted ;) :).

Eric Hogue replied on Thu, 2011/07/14 - 7:35am in response to: Alpar Gal

Hi Alpar,

Thanks for the comment, I'm glad you liked the review and Uncle Bob's book.

You have a good point about the release date. But seriously I would had really needed this book earlier in my career. Maybe if I could go back in time. The good news is that my career is still young. Especially if I compare it to Uncle Bob who started programming a few years before I was born. So hopefully I still have many years to apply the lessons from the book

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.