A Code of Conduct for Professional Programmers - The Clean Coder

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!

I'm really glad Bob wrote this book. I encourage every programmer and manager who works with programmers to read this book. We need more professionalism coders.

My only complaint is that it ended abruptly and the chapters didn't really flow together; instead, each chapter felt like a long, well done blog post.

The kindle version, which I bought, was just fine.

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.

Hi,

This book was purchased after I read "Clean Code", which is truelly excelent.
I found the book too personal and "biography like". Too many repetitions, and even typos ...
A dissapointing book.

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.

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.

The only shortcoming I found about this book is the name. "Clean Coder"? It's a bit misleading since "coder" makes you think about (what a shock) coding. Which isn't at all what the book is about and it seems that the vast majority of negative reviews are about missing the point of the book. This book isn't:
- about an approach to programming (see "Pragmatic Programmer" for a great book on this).
- about development methodologies (see any book by Ken Schwaber on Agile or look for any methodology works on stuff like PRINCE2, LeSS, Waterfall, etc)
- how to code (insert a book on your favourite language/platform here).

This book is about how to behave as a programmer in front of project challenges. Starting from approaching problem solving, human interaction with various roles (like vs PM for example), how to pursue better code (sadly the author is dead-set on TDD even though BDD has started to overcome TDD due to being more flexible). Like the author says, it's about how to be a professional in the true sense of the word.

Particularly I like:
- how to stay 'no' and stand by it. Basically it boils down to hanging on to realistic answers as anything else is misleading and unprofessional (your commitment as a developer is to delivering quality, not to saying 'yes' all the time)
- how to better yourself (doing coding katas, exercises, keeping in shape) and never to expect the employer to invest in you. You invest in yourself and anything the employer offers is a bonus.
- you shouldn't try to justify technically to non-technical people, it's wasteful and suggests people don't trust your professionalism.

I disliked:
- the author's hanging on to TDD as a unit-test methodology. Yes, at some point he does notice (exactly one sentence) that there are some rare cases when TDD may be unsuitable. He completely disregards BDD, which is particularly popular with outsourcing projects due to more flexibility and end-result orientation rather than pure unit testing (no, not even TDD is about unit testing only).
- he does know Scrum, but seems to skilfully avoid framework updates that came in the past two years. I say this with respect to the implications of some of his statements.

All in all, this is a really great book with plenty of insights for developers, testers and various managers.

Uncle Bob Martin's eagerly awaited sequel to Clean Code, cleverly named The Clean Coder, is a powerful argument for professionalism in software development. People who'll benefit from this book the most are programmers at the start of their careers or those who are burned out and work with software and companies plagued by technical and organisational issues. The book has a lot of sound advice to offer, in particular around commitment, planning and estimation, personal ethics and collaboration, as well as an overview of techniques such as TDD, pair programming, and automated acceptance testing.

The gist of the book is, for me, captured in the following quotes:

- "You can't take pride and honor in something that you can't be held accountable for"
- "QA should find nothing"
- "The true professional knows that delivering function at the expense of structure is a fool's errand."
- "Woe to the software developer who entrusts his career to his employer."
- "Professionals speak truth to power. Professionals have the courage to say no to their managers."

Those who don't suffer that much from poor team or software will not benefit that much from The Clean Coder, but there are a few gems in for them as well. I found the argument against flow (or "The Zone") particularly interesting, as I've never looked at the topic in the way described in the book. References to probability based estimation were also interesting, as well as explanations of some more exotic time management strategies. Most importantly, through many interesting war stories, we as readers get to peek into Uncle Bob's experience and learn from his mistakes.

If I was picky and had to choose a few negative things to say, I'd probably point out the start of the book as unnecessarily off-putting and negative. It paints a picture with a clear adversarial relationship between programmers and management or clients, which doesn't really match my background or current situation. Sure there have been a few bad apples in my project basket, but the picture painted was a bit too negative for my taste. On the other hand, people who need to hear the message of this book will probably identify with that dark painting of their reality. I've also never been good at reading books with lots of invented dialogue, something in my reading circuits makes me skip invented conversations. This made it hard to follow the flow of thoughts in some parts of the book but it has more to do with my attention deficit and reading skills than the book itself.

So to conclude, this book is not going to replace the Pragmatic Programmer as my favourite "you have to read this first" suggestion to new members of our profession, but it deserves to be on that list.

I just finished reading Bob Martin's _The Clean Coder_. I understand why he used that title, but I would have preferred something like _The Software Professional_ or _How to Really Enjoy Your Software Career_. The lessons in this book are essential for everyone involved in delivering software, not only the programmers.

Uncle Bob doesn't hesitate to share painful lessons he learned the hard way over the early part of his career. Maybe the best reason to read this book is to see how he actually learned from his mistakes (and those of others). Often when we make mistakes, we're tempted to blame someone else for them. Bob doesn't hold back, he's not afraid to describe his worst decisions, and he lays out in detail what he did to improve and ensure future success.

The stories make the book an easy and compelling read, and the advice on how a true professional behaves may make you squirm (I did, at times). I've been guilty of being a bad team player by saying "yes" or "I'll try" when I should have said "no". I don't pair very much in my day-to-day work, when doing so would improve the quality of my work and our product.

I cheered as I read Bob tell us to continually learn, and to learn things outside our comfort zone. I've been focusing on this the past few years, and I do feel I'm a much better professional and more valuable team member as a result.

So many insights in this book were an "aha" moment for me. For example, Bob explains how it takes time for a team to "gel", but once they do, magic happens. I realized that the reason my team rocks is that we "gelled" years ago and have been able to keep working together, always finding ways to work better. We're so fortunate that no manager has tried to break us up (and so is our company!)

I was a bit shocked at the production values of the book. The copy editing and proof reading was not up to par. There are typos, mispellings, inconsistencies, and some index entries point you to the wrong pages. Given that this book is from the same publisher as my own books, I'm concerned about their own commitment to quality.

The only thing this book is missing IMO is a Big Finish. The last sentence in the book describes Uncle Bob's Macbook Pro. I was expecting him to exhort us to go forth and be true professionals.

So I'll do the exhorting. Read this book. It's short and it won't take you long. Follow Uncle Bob's advice and start behaving as a true professional does. It will make you happy, make your teammates happy, make your employer (or perhaps your future employer) happy.

This book will immediately improve the quality of your work and communication with team members, managers, and customers. It's really about project management and full of very useful tips, sharing experience that would take you decades to acquire. Of course there are lots of specifics on how to improve as a programmer, but it applies to everyone. The name & cover may make it look unappealing, but don't let that fool you - this is not another self help book bloated with repetitions. I think this should be a textbook for IT degrees, if it's not already. In short, very impressed, and it affected my work life already!

I found the book entertaining, full of personal anecdotes, showing how the author became the kind of professional developer he is considered now. Some people may say that it's nothing new to them, that they knew all the work ethics and beyond-coding (social, emotional, organizational) skills since they startet their job. But many don't, and so the book is mostly a good advice in everyday life "on the job", never boring and not from the position of a "coding god", but somebody who had to learn it all himself the hard way. He even admits having been fired for sloppy behavior which is somewhat common to many developers, from a company strongly emphasizing formal discipline, like wearing a tie or being at work in time. I think many young developers get themselves a bloody nose once or multiple times in their career. Having a non-"has always been" professional telling his story is quite useful to guide someone on the long and hard way to professionalism which one still continues to go when in the 30s, 40s and older.

However, the book strongly advises the programmer to adopt a kind of "robot behavior" with main focus on discipline and external demands, not the kind of individual, team avoiding, interest driven kind of work that has been typical for many developers for ages. He even advises against working in a state of "flow experience", or "The Zone", where a developer feels one with his job, one of the most important sources of satisfaction and creativity in a development job. This is a permanent conflict: Developers must of course meet external demands to get their software sold and their salaries paid, but it is great if there is some degree of freedom, rather than having every second planned for efficiency, if developers can live with their machines and code, rather than being expected too much social and organizational skills. I think software development should remain as a refuge for people who work better alone with machines. Not everybody has skills and talent for everything, so let people do what they actually can do!

However, everybody will need to aquire some more professional behavior than when POKEing around with his VC-20/VIC-20 at the age of 12, but there are certain boundaries and limits which are very hard to expand. Martin describes these critical points well: for example, being under pressure by a superior and making all kind of mistakes just to release the pressure for the moment: make impossible commitments or say you "try" (an indirect commitment, at least to very excessive work). Or rushing, trying to get things done "quick and dirty", which is actually slower. It's easier said than done when you're expecting to get bawled at or even fired if you tell the truth, that expectations are not possible to fullfill and you refuse to commit. There's a lot of professional behaviors you know you should do, but which are very hard, sometimes impossible to actually do. Not to do "Priority inversion" is another such thing: "Professionals evaluate the priority of each task, disregarding their personal fears and desires, and execute those tasks in priority order" - really hard and not always possible if the most important work is a really tedious chore and you have way more exciting jobs in the pipeline.

Fortunately, much of the automated testing and TDD Martin advises, does a good part of the ordering and structuring of work - it's our job to let machines do the unpleasant tasks in the world, so we should make use of this, too!

Another thing the author writes about are the unwritten rules of the working world, which you learn neither in school nor university and likely not at home: Misbehavior in his job (being late) was not openly complained about, but very well noticed. A dangerous trap for many who can adapt their behavior only to explicitly expressed demands and external control. The warning letter and the complaint by the author's boss did not mean what they said, that he should urgently change his behavior. Instead, they meant he is on the hit list and should look for a new job immediately. One has to learn first that when an open complaint by the boss comes, it's usually not critical, but already five minutes past twelve, and you can't save your job, no matter what you do. On the other side, absence of complaints doesn't mean everything is o.k. Especially for newbie developers, the book can be very helpful on such topics and save them perhaps from quite a few unpleasant experiences.

The highly professional "Clean Coder" is usually not born as such, nor does he/she get full education for this at university, from books or coding web sites. He's a product of many years of experience, often including severe failures. This book is, as I think, helpful to accelerate the individual development a bit. I hope, on the other hand, that at least a fraction of software developers in the future will be spared from too much of "soft skill" demands (social, emotional, organizational, communicative) and can continue their lives as respected, smart code and machine loving nerds. But a minimum of these soft skills will be inevitable. Many of the non-technical skills described in the book may seem obvious to somebody with a strictly disciplined education or who has gone through decades of work life, but they are not for everybody!

I found the author's tone extremely judgmental and offensive.

Examples:

You're not a "professional" programmer unless you are working at least 60 hours a week. This is total baloney! And in his world, it's fine to be paid only for 40 of them!

If a programmer creates a bug that costs the company $10,000, then the programmer should write out a check to the company for $10,000 - that is, if he's a "professional." This is ludicrous. Why wouldn't QA and other teams contribute as well? He acts as if the programmer has the greatest responsibility within the organization and should bear the greatest burden.

The book reflects the experience and opinion of its author, but I had expected more than that: researched subjects and more nuances. As examples, and as mentioned in other reviews, the chapter on music and the 20h of personal work a week are really not convincing.
It's still an interesting reading, but if you do read it, keep some distance, it's not the Truth.

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.

Based on other writings from the author, he does understand what Professional Programming is about. While I agree with his recommendations about professionalism in programming, this book does not do it for me. Maybe he should have applied a similar code of conduct for professional writers when writing this book.

This book is a rather mixed bag of Test Driven Development advocacy, generic statements on project management and time management and personal anecdotes. Most of this could be timeless if the examples were more generic. The anecdotes all seem from an era when most of the people who should read this book were in diapers at best. They don't do much beyond giving the impression the author is pretty much out of touch and weakens the generic statements. The only paragraph that is clearly less 10 years old appears to be a last minute addition and seems to be typeset differently. The book lacks structure to serve as a reference and lends itself best to reading from front to back. But reading the book like a novel, it is annoying that the author is repeating himself several times and the same anecdotes keep showing up in different chapters.

I don't believe that the suggested approach to practice programming the same single showcase over and over will improve your programming skills. While practice helps, you should practice applying the techniques for programming different cases, not just practice your typing skills by typing in the same program hundreds of times as suggested.

If you're interested in Agile Development or TDD, then read a book about that. For some perspectives on professional programmers, read some blogs and short articles (including Uncle Bob's).

The book contains very useful information about the profession that is not usually covered in school but is essential in profession development. If you have a couple of years of experience in good companies this book won't add much new from what you've already learned though.

If you are considering this book because you are new to the world of software development, do yourself a favor: go find an experienced (10+ years) developer who has no reason to lie to you (i.e. you do not work for/with him) and ask him to describe his experiences in the profession. Do this over and over. Take what each person says with a grain of salt, combine it with your own real world experiences and come up with your own set of ethics and beliefs.

Software development is a field historically dominated by strong individualists. I'm not saying that there isn't a place for "company men" in our profession, just that they don't fare as well over the long term as do those who intelligently look after their own interests, first.

You don't need someone else's "Code of Conduct". Discover your own.

I read the Kindle sample, fully intending to buy this book, but they lost the sale with the forward. It was well written but wrongheaded. While it wasn't written by the author, the author did include it in his work. The thought of wading through more of the same was exceedingly tedious.

Too much "diddly doodly" and fairy tales for a book that is supposed to help build professional programmer.
Real life a little more complicated that that (and by the way, this is stated in the book but in a way that seems a distant past).