DevOps Zone is brought to you in partnership with:

I help organizations with effective software development and management practices: continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. Ben has posted 3 posts at DZone. You can read more from them at their website. View Full User Profile

Book Review: Uncle Bob's "The Clean Coder"

06.28.2011
| 9737 views |
  • submit to reddit
Published by: Prentice Hall
ISBN: 0137081073

Reviewer Ratings

Relevance:
5

Readability:
4

Overall:
5

Buy it now

One Minute Bottom Line

The Clean Coder is about how be a professional programmer, who communicates clearly about what will be delivered when, and lives up to these commitments.

Review

The Clean Coder

The subtitle of this book is “a code of conduct for the professional programmer”. That already makes clear that this is not a book purely about programming methods or techniques, though it covers subjects like testing strategies a coding. It is about attitudes, discipline,  and being a professional programmer. Let’s take a more detailed look at some of the topics that are covered in this book, to give an impression.

 

Professionalism

Professional means having the right attitude, being disciplined and taking action. Some of the examples described in book are about taking responsibility when the software that you delivered contains defects (up to paying for the damage), testing all software before delivery, assuring that the software remains maintainable and learning and practicing new techniques. Yes, those are just some of the examples, this book is very serious about what professionalism is, and what is needed to become a professional!

Professionalism doesn’t come for free. You need to invest personal time to develop yourself.  Also, you need to learn from mistakes that you make, to prevent that you make similar mistakes in the future. You need to exercise your programming skills, for instance by participating in a coding dojo. Even better is to do some teaching or mentoring, you can learn a lot from helping others to develop themselves.

 

Saying No and Saying Yes

No and Yes are two simple words, yet this book makes clear that they are often not used correctly when agreeing upon delivering software. The book describes many examples on (mis)communication between managers and programmers, on the estimation, planning and development of software.

A professional developer must be able to say No. Say no, when (s)he cannot guarantee that a deadline can be met., or when a proposed solution for a problem is not doable.  Giving hope by saying “I'll try” is not an acceptable answer. I had a manager who used the saying “hope is postponing disappointment”. He wanted to know if date could or could not be met.  And he wanted to know any delays as soon as the first signals were there. If you came to him late in the project announcing a delay, then his first question would be if you already cancelled your plans for the coming evenings and weekend. If you informed him as soon as possible, then there was always a solution to be found.

Saying Yes means commitment. It means that you will deliver on time, or that your software will not have defects, no matter what.  You say it, you mean it and you do it. Sounds simple, but it’s not always easy. Of course you already said no to the things that you can’t do, so when you say yes you are convinced that it is doable. Which means  that it is within your control. If it turns out along the way that you cannot do it, take action. And if you didn’t live up to your commitment in the end (for instance if the test team finds a defects), apologize, solve the issue, and learn from it.

 

Pressure and being disciplined

The book gives hint and tips to avoid getting under pressure, for instance by being clear on you commitments, keeping your code clean, and assuring that all code is tested before delivery. But you can’t always avoid it, so sometimes you have to work under pressure. Then you have to be disciplined, and develop software the way that you know is the best way (given the situation at hand). Bob give the example of a surgeon, who when working under time pressure will perform the surgery together with the team of specialist in the way that they have been taught and know. Instead of starting to yell and slam and throw instruments. Surgeons working in an undisciplined way are not allowed to operate, for obvious reasons. So why should it be different for programmers?


Conclusion

Reading this book made me aware of what professionalism is about. The book is full of stories and experiences from the author’s career. The examples make it easy to read, and they also appeal to the reader to take a look at his own experience, and to learn from it. And that is what a “clean coder” is all about, delivering high quality software, on time, in a professional way.

 

Ben Linders (www.benlinders.com) is Senior Consultant on quality, process, and organizational improvement with more than 25 years experience in implementing high maturity practices to improve performance and deliver business benefits.

Published at DZone with permission of its author, Ben Linders.

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

Comments

Andy Till replied on Wed, 2011/06/29 - 9:24am

I wish you would not propogate this Uncle Bob name he has come up with, I find it incredibly creepy.

Ivan Kirkpatrick replied on Fri, 2011/07/15 - 9:37am

As a consultant I have always tried to be as professional as I can and I have seen many examples of less than professional behavior from others. As a team lead in one engagement the manager asked me to stop using the word professional when discussing the tasking and job performance of the other developers.

One thing I have found is that despite my efforts to adequately test my software bugs and issues still pop up. I take this to be an indication of less than complete testing, despite my 100% coverage. It really means that the some of the tests are not good enough. This forces a review of the test or tests and sometimes additional tests to be added as well as correcting the code. the real benefit is in the long term when I can quickly get back into the code, and enhance it for new features with confidence that the tests will help identify any regressions.

I like Martin's book on on Clean Code and consider it one of the best guides I have.

Comment viewing options

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