Customer Reviews

The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin Series)

5 star:		(11)
4 star:		(9)
3 star:		(0)
2 star:		(5)
1 star:		(4)

 

 

This book is good at providing a general overview of what it means to be a software professional. Lots of good advice and provides many resources and a general framework for thinking about the subjects he presents.

Sometimes the author presents strategies very specific to him that wouldn't work for me. For example, I tried the pomodoro method before and had mixed results. I think readers would benefit more looking at the goal (better time management) and finding a methodology that works for them to accomplish that goal.

He is very bullish on unit tests, stating that there is no longer and controversy over TDD. As a huge fan of unit tests, I find many places I have worked at have very little interest in unit testing or don't see any real benefit.

The book is also very strongly against being in the Flow to program which I found interesting. This is pretty much 100% the opposite of everything else I have ever heard/read.

He is also against listening to music while programming. He provides a weird example where while listening to Pink Floyd his code comments had Pink Floyd references. The author has a tendency to confuse something that is true for him ("I don't listen to music while programming") to a general universal rule ("Programmers shouldn't listen to music while programming").

Most programmers I know who listen to music do so as white noise. For instance, I listen to techno many times while programming. I don't like techno but the droning drum servies to drown out the office chitter chatter at my current gig.

Like Clean Code, I don't always agree with the author but provides good food for thought and is worth the read!

Overall, I would say this book was disappointing. Admittedly, I had high expectation after reading "Clean Code". Perhaps it was the rather too personal anecdotes that initially turned me off. I would say you are better of reading "Pragmatic Programmer" and a book on Scrum XP and software project estimation.

As other reviews have said, it feels like a collection of blog articles published in a book.

Chapter 1. Professionalism

The book got off to a bad start for me... the first chapter on professionalism:

"Do the math. In a week there are 168 hours. Give your employer 40, and your career another 20. That leaves 108. Another 56 for sleep leaves 52 for everything else.

Perhaps you don't want to make that kind of commitment, That's fine, but should not think of yourself as a professional. Professionals spend time caring for their profession."

Really? 20 hours per week; so if you spend 10 per week reading blogs, listening to podcasts, doing kata's etc... you are no longer a professional? While I agree, you have to take personal responsibility for your career, asserting that you have to spend 20 hours a week seems over the top to me. Perhaps the author wishes to be controversial and overly opinionated to provoke debate?

Chapter 4. Coding.

The section on listening to music while coding has a truly bizarre anecdote:

"One day I went back into a module that I been editing while listening to the opening sequence of The Wall. The comments in that code contained lyrics from the piece, and editorial notations about dive bombers and crying babies."

I'm guessing lots of people listen to music while coding without a problem. I can imagine, if I had been working 80 hour weeks for the last month, I would something similar, but surely that is a symptom of being on a death march?

I liked the section on false delivery. It can sometimes be difficult for everyone to have a shared understanding of 'done'. A former Scrum Master used to have a short meeting whenever a new team member joined us to cover the "definition of done".

6. Practicing

I'm a little skeptical of repeatedly doing the same kata; yes create side projects to spike a new technology that you wish to learn about - but I'm not convinced that continued repetition of kata helps.

9. Time Management

I was glad to read, that it is OK to decline a meeting. It validates my practice of declining meetings without an agenda/ goal/ deliverable.

I liked the advice, on how to leave a meeting that you are not adding value to and from which you are receiving no value.

Focus-Manna

I thought this section contradicted what the author mentioned about 'The Flow Zone' in chapter 4.

"We write code when our focus-manna is high; and we do no other, less productive things when it's not.".

On the Zone - "It is the highly focused, tunnel-vision state of consciousness that programmers can get into while they write code.".

10. Estimation.

The following excerpt I found very peculiar - "I've only been drunk two times in my life, and only really drunk once. It was at the Teradyne Christmas party in 1978. I was 26 years old.".

14. Mentoring, apprenticeships and Craftsmanship.

I felt this chapter could have been longer, with more depth and more concrete proposals; this chapter should of been the highlight of the book - as the most of the themes of the book are either covered in depth elsewhere or are part of best practices/ agile bandwagon (TDD, unit tests, acceptance tests). It would have been nice to provide more information about efforts the IEEE or the ACM are doing to promote the idea of software professionals. A discussion on certifications may have been useful.

It felt like the book ended rather abruptly with on Tools. It seems this chapter is going to make the book dated very quickly; whereas a book on titled "The Clean Coder: A Code of Conduct for professional programmers" should be timeless.

In "The Clean Coder: A Code of Conduct for Professional Programmers," Uncle Bob Martin is his usual, controversial self, but he is often convincing. One upshot is that I will never again tell a manager that "I'll try" to hit an overly ambitious deadline: I will either commit or refuse to commit, or offer an estimate of the odds of success. On the topic of deadlines, Martin observes that project managers and "suits" regard completion dates as commitments, while programmers tend to regard them as estimates, usually overly optimistic estimates. He makes the case that it is the professional duty of programmers to come up with realistic estimates and then stick to their guns.

Another good point Martin makes is that a professional programmer should take the responsibility to hone his or her skills outside working hours. He recommends working a focused and productive 40 hours a week, and then spending 20 hours a week on career development: reading, learning other languages, even practicing programming "katas".

One of the most controversial claims Martin makes is that getting into "the zone" - that mental state of total concentration for which programmers strive - is a bad idea, because it results in too narrow a focus. Personally, I'm not convinced. I think that the problems of focused programming can be remedied by being sure to take a big-picture view from time to time, and also by code reviews.

A problem with this book is Martin's use of overstatement to indicate emphasis. So when he says "never, never, never" agree to meet a deadline by working extra hard and long, he means "hardly ever". His insistence that agreeing to accelerate effort inevitably result in low quality code just does not wash. Not that it can go on forever, but my own experience is that a brief and intense push can often get things done faster without sacrificing quality. Even Martin's suggested regimen suggests that there is slack in the schedule: surely the 20 per week of career development could be sacrificed from time to time. I shudder to think of a mid-level programmer, influenced by Martin's rhetoric, refusing to work extra hours "on principle", thus harming both his own career and the prospects of his company.

With that caveat, however, the book has much sound advice, and is an excellent read to boot.

The clean coder is sort-of a follow-up on Clean Code. Where Clean Code explained how the code of a professional developer should look like, the Clean Coder explains what it takes for a developer to consider themselves a professional. The book is fairly small (200 pages) and it is an easy and quick read. The chapters are small and coverage is broad (and thus narrow at times...)

The book consists of of 14 chapters. Each chapter covers an aspect of software development and describes Bob's opinion on what it means to be a professional in that particular aspect. The first chapter is an overview. Chapter 2 and 3 talk about the ability to say NO! and not being pressured or talked into unrealistic promises and about how serious you ought to take it if you do say yes.

Chapter 4-8 discuss development-focused practices, from coding (4), to test-driving (5), practicing your skills (6), working with the customer by acceptance testing (7) and different strategies for testing (8). Each of the chapters is short that it doesn't really talk about the concepts, but it points out some important parts and explains why it is important for professionals to act a certain way.

Chapter 9-11 are more time-practices. Starting from Time Management (9), Estimation (10) and dealing with pressure (11). These chapters also strongly relate to the "Saying No" chapter (2) of not making unrealistic commitments and the "Saying Yes" (3) chapter of letting "Yes!" actually mean something. Especially the pressure chapter is one that the reader probably ought to read several times :)

Chapter 12-13 discuss about professionals working together with other people, with customers and with other developers. Chapter 13 is a little off as it covers a bit more on organizational structure to make efficient teams than how to act as a professional developer.

Chapter 14, the ending chapter, covers mentoring and craftsmanship. It stresses (a topic Bob often repeats) how silly it is that even McDonalds employees are better mentored in their job than an average SW developer. It envisions a better way of growing great developers in organizations.

The Clean Coder is an important book as there aren't many book on the topic of behavior of individual developers. Especially the topics related to developer behavior under pressure and making and avoiding commitments are, in my experience, of most importance for good software development... yet rarely discussed.

The book is an important book, yet I felt disappointed at times. Most topics are covered really shallow (keeping the book small) and at times it felt Bob was just cherry-picking a couple of practices he felt important. Also, at times, I felt the book was inconsistent with itself. For example, one of the things that annoyed me, is that in Chapter 1 he talks about professionalism and how one aspect of professionalism is to "know your field". Yet, in the chapter of professionalism he doesn't at all refer back to earlier attempts on the same subject. He doesn't refer to After the Gold Rush: Creating a True Profession of Software Engineering (DV-Best Practices) or about the attempts of IEEE and ACM of defining our profession. If you are writing on the subject, and tell people they should "know the field" then at least you ought to refer back to the earlier developments in "the field". Similarly, I felt the book is seriously lacking references to further study on the important practices that are covered.

The Clean Coder is also a very personal book. Bob is obviously the Clean Coder in the title and the definition of professionalism is his definition of being a professional. The book is full of stories from Bob's long career that helped him reach these conclusions... what it means to be a professional. I enjoyed the stories from his career a lot and it makes the book at times, almost an autobiography...

Conclusion. At times, I though this is definitively a 5 star book, yet at times I felt it is just average and shallow and doesn't deserve more than 3 stars. In the end, for me, it was the topic of unrealistic commitment that forms the skeleton of the book that I decided on 4 stars. It is less good as his earlier 2 books Clean Code: A Handbook of Agile Software Craftsmanship and Agile Software Development, Principles, Patterns, and Practices. But it is definitively an important book and worth reading, especially when you want to help building a true profession.

This is not a treatise on professional ethics, but another collection of personal advice and war stories. The advice seems sound, but, for the most part, is not surprising: Don't over-commit yourself, write automated tests, reserve time to learn and practice, get enough sleep etc. Even so, I felt this short book was worth the time; if nothing else, it will refresh your good intentions and get you thinking about your everyday practices.

In popular culture, computer programmers, sometimes confused with sysadmins, are often described as teenage punks, sitting in a dark, lit only by the glow of their monitor, empty cartons of pizza and Mountain Dew bottles scattered strategically around, frantically hacking away on their keyboard.

What does it mean to be a professional programmer? Is it wearing a suit and tie to work? Is it having certifications or diplomas decorating the walls of your office? Is it working hard, sometimes overtime and weekends, just to show your dedication?

To Uncle Bob, this is not what professional programmer means. The things commonly mistaken for professionalism, such as a dress code, are not what's important, at the end of the day. Having developers act professionally towards the code and towards each other, however, is.

"Clean Coder" is a collection of anecdotes and stories about the 42-year programming career of Robert Martin, and he shares his rich experience of what it means to be a professional programmer. It's knowing when to say no even to the most persistent of managers, and saying yes by committing to a task, and standing behind your commitment. It's writing the best code possible by not sacrificing any of the principles of good coding practices, even in times of pressure. It's asking for help and helping others, instead of hacking away with your headphones on.

If you value your chosen profession, you should definitely read this book, especially if you are working in less-then-ideal corporate environment - it's up to you to drive changes in your work place, if the settings do not allow you to act professionally. If your company is not using source control - set it up yourself, and make sure to teach your team how to use it. If you're not writing unit tests or waiting for QA to test for bugs - learn how to test your code, so that you'll be able to know for sure that it works. Keep your skills sharp and your tools sharper. That's what it means to be a professional programmer!

A colleague of mine recommended this book and its predecessor (Clean Code). I have not read Clean Code yet but decided to read this one first. This is a good book on professional code of conduct for those graduating out of university and venturing into professional arena - to these folks this book gives pretty good advice or at least provides a pretty good starting point. For those who already spent several years in the industry such as myself, a lot of what he has to say would be obvious - in that case one's own professional experience would have taught most if not all of what the author advises on. For instance consider the quote from chapter 2 - "Professionals have the courage to say no to their managers". I learnt this lesson (the hard way) in my career. Now it would have been better if I had learnt it sooner from other people's experiences. That said, I do believe that there is a limit to how much you can learn from experiences of others (and more importantly in some cases, there is no substitute for one's own personal experience). This book covers a lot of topics from mentoring, project management, test driven development, career enhancement, handling pressure etc. A few ideas took me by surprise - for instance, the author states that the true benefit of mentorship is for the mentor - I never thought of it that way. I certainly don't agree with everything in this book although I can appreciate the author's perspective most of the time. For instance, there are a fair number of references and comparisons to medical profession which in my personal opinion are not really appropriate given how different both professions are. On the other hand, I can validate others by looking back - for instance the author talks about allowing teams to gel and once that's done high productivity is achieved and therefore a gelled team shouldn't be broken. There are some good ideas in this book which I plan to try out and see how well they work. Overall this book is definitely worth a read for entry level folks and not really necessary for folks with profession experience.

I agree with many reviews on both sides. He makes good points about yes and no, but gets very dogmatic and hard-lined about some issues like TDD that could use some proof or convincing. He comes across that if you don't agree with him, you're not a professional. I need more than that from a book. I want to understand why, so I can integrate the author's opinions with my own experience and opinions and what I've read elsewhere.

For example, I see value in tests and writing them as you write code, not after, but I would be interested in arguments for a very tight test/code cycle. Arguments that address what wisdom there is in knowing your tools well enough that you know what your wrote and how it will work (that you know what your wrote). Arguments that also address the fact that it's just unit testing and there are limits to the feedback you get from them. A customer is not vetting your code, so any mistakes you make with regard to requirements, or understanding the problem, are still reflected in the test. Unit tests are good. Writing them as you write code keeps you on top of it, but they aren't the end-all. Coverage is something to be proud of, but it won't tell you if you are building the wrong thing. Martin writes with such emphasis for TDD, without mentioning it's limits that some might be mislead.

I'm an experienced developer with over 20 years of experience to draw upon to temper and evaluate any rules presented to me. While I think there are some good points in here, they aren't justified well enough for a beginner to understand these opinions and integrate them thoughtfully into their own practice. Just as a coder should have a good understanding of the fundamentals of their tools, of why things work they way they do, eschewing black magic, so should that coder understand process and guidelines such as those presented here.

Read The Pragmatic Programmer by Dave Thomas instead. Consider also Rob Pike's The Practice of Programming, maybe The Unix Philosphy, and even stuff like Peopleware (Demarco and Lister), Software Craftsmanship (McBreen), and Professional Software Development (McConnell) first.

This title joins my set of books which should be read by every developer aspiring to become better and better. It shows how we, as developers, can behave as a professionals and as a result be perceived and treated like professionals. Robert C. Martin basing on his experience (did you know that he is a programmer for 42 years!?) shows us how to improve or change our habits, our communication and collaboration skills to become more valuable part of our team, our company and finally our client. Below I present some main thoughts from some chapters of this great book.

There are many quotes from this book which joined to my favorites so if you read it (and I strongly recommend it) you will probably find a set of wise sentences and thoughts inside too. And then, after rethinking them, you will be a few steps closer to become a better developer. And from who should we learn if not from Uncle Bob and his 42 years of experience?

The Clean Coder is essentially sitting down at bar next to an old-timer and listening to him spout this theories. You will agree with some and want the bartender to cut him off for others. There are lots of anecdotes which can be fun to read. However, there is no science here, just opinion. Worse, the book contains many fictional dialogues which supposedly make some point or another.

Throughout the book, Uncle Bob makes an impassioned argument for Test Driven Development with the religious fervor only a former sinner can muster. He takes the hard line, "if you are not doing TDD, you are not a professional programmer." Techniques change with time. The problem with this sort of morally absolute statement is that in ten years time, new code development techniques will be emerge (Design by Contract in my opinion will be one of them). At which point, will Uncle Bob say "if you are not doing <fill in the blank>, you are not a professional programmer." in The Clean Coder2? He probably will. So, why listen to him today.

In the end, I cannot image that reading this book will make anyone a better programmer. There are some fun stories though.