The Clean Coder: A Code of Conduct for Professional Programmers

Programming is an interesting profession. It’s not just an engineering exercise, where you’re building the most logical, structured, and well-designed application according to some set of industry best practices; rather, there’s a great deal of creativity that goes into it – an artistic quality, if you will. Instead of solving a particular problem the same way for every project, you must creatively adapt your thinking and communication to meet the expectations of each project’s stakeholders. Programming is not well understood like other professions. You know what lawyers, accountants, and doctors do. Their workflows and processes are well known since their professions are mature and a good portion of the population has interacted with them directly or indirectly. Programming, on the other hand, is different. To many people, a website or software solution magically just “appears” after a programmer spends time at his or her computer. Enter Robert C. Martin’s The Clean Coder. The Clean Coder helps demonstrate how programmers can conduct themselves as professionals, removing that black-box quality and holding themselves to standards as other professionals do so they garner the same respect from their peers and can help others do more with technology. I’ll talk about some of the lessons that really resonate with me: In the forward, Matthew Heusser relays a story about how his colleague, Joe, considers “estimates” from the technical team and “estimates” from the legal team with completely different mindsets. In short, Joe considered legal estimates to be final, whereas technical estimates were negotiable. Why weren’t estimates from the two teams treated equally? In my career, I’ve seen the same thing many times, largely stemming from three reasons. First is the assumed “magic” that non-technical people think programmers wield. Throughout the book, Martin explains how to remove the veil of mystery regarding said magic. Second is that I’ve run across others that compared us with their profession and made some assumptions, such as, though a harsher example, we’re being lazy or noncommittal. Here, the author discusses how to address such assumptions when confronted with them. Third, and the most important part that we can influence, is the tech person’s mindset and approach to work. From the text, the programmer learns how to craft their own mindset and workflows to handle these. In essence, we can’t make things perfect, but we control a lot of parameters to make things better. The first three chapters cover the conduct that a software developer professional should exhibit. A recurring theme within all three chapters is that software developers should take responsibility for what they say and do. Martin gracefully simplified this down to: how/why to say “no” and how/why to say “yes.” For example, if a developer agrees to a timeline, then they should make the timeline. If there are risks or unknowns on something you’re defining a timeline for, don’t agree to it, but rather just agree to what you can commit to if possible. The key is to not let yourself get bullied into agreeing to something you know you can’t meet with confidence. Others will build their own schedules and commitments around what you say, and there may be serious repercussions and loss of face if you fail to deliver. If you’re not as accurate as possible, you’ll erode the trust you have with your colleagues. Along with controlling and defining your commitments, you need to take responsibility for your work output. Specifically, being a professional means that you certify and guarantee that your work output functions. For example, accountants ensure that their accounts balance when they finish closing out the books monthly, quarterly, and year’s end. If they left discrepancies, they would soon find themselves out of work. However, developers seem to be able to deliver questionable code or features that just plain don’t work, again and again. I understand why: development is hard. There are a lot of moving pieces and people in a software development project; as a result, there are a lot of rules that get balanced when you go in and change something. None of that takes away from the fact that developers lose trust of their peers when they fail to deliver working solutions for the tasks assigned to them. They’ll probably remember the failure (their label, not yours) instead of the nuanced “whys” that caused that failure. Luckily, software developers have tools available to them to prevent this from happening, but only if the tools are actually put to use. Martin’s philosophy around testing is something with which I completely agree. The only way you can truly know that what you’ve added or changed doesn’t break everything else on a project – regardless of size – is to test it and have a structured, scalable approach to testing. Manual testing takes time, sometimes A LOT of time, and you leave a lot to chance that way. Hence automation. When automated, a test can be written once and then just be executed. It makes it trivial to repeatedly ensure that your code matches all the criteria it needs to meet. (Note: I wouldn’t recommend this approach across the board, particularly if an MVP, pilot system, or feature with a lot of changing specifications is being created, which is quite common with my startup customers. For something mature, scalable, and maintainable in a financially feasible manner, it’s required.) Martin’s discussion of “expected criteria” is another area that is really important for developers to understand and put to use. Ultimately, a customer or stakeholder will have to accept the software that a developer builds. When is the software done? What do clients judge the system’s success by? What aspects of the software do they value, and how do they prioritize what they value? To address this, I've always operated from the mindset of: the software is done when the customer tells me it's done. Part of that determination is working with the customer to define the acceptance criteria, though that can be difficult if the customer is non-technical or busy. Even high-level criteria are helpful, such as "Search for a product, and buy it” or “Load fast.” That’s fine so long as the stakeholders are open to iterations later to arrive at what they truly want. Conversely, the criteria could be very specific. Ideally, the developer helps the customer put more definition on their acceptance criteria throughout the process. The more quantitative, the better. The developer is finished with the work when they deploy or deliver the software or functionality that meets all the acceptance criteria. In conclusion, it’s not so important how the acceptance tests are written even though there are best practices; what is important is that you and the client know what is “done” and agree to it. The book is chock-full of other applicable advice as well, from numerically-driven ways to handle estimates to suggestions for interacting with colleagues. All of the recommendations align to the goal of helping developers comport themselves as professionals so they’ll be treated as such by other professionals. It’s very important because our work is nebulous and our profession is new. I highly recommend this book to anyone who wants to be a professional software developer for the long-term or works a lot with them.

I thought this would be about details of a type of coding or coding practice. I can't say I enjoyed the book but I learned a great deal from it. This book deals with the philosophy and ethics of being professional first, and being a coder second. It brought home a lot of flaws that I've displayed across the years. That's why it wasn't all that enjoyable; the writing was all too clear and direct. Although I've been around IT for some time, I've only recently started working directly with professonal developers. That was my motivation for buying the book -- so I could do a better job and maybe earn a bit of respect. It did introduce me to Test Driven Developement (that in itself ought to reinforce that professional coding is new to me). After just one day of trying it I find that I pick up after distractions much faster, cover more cases to test, and even write in such a way the code seems to document itself without the huge effort I've had to make in the past just to get so-so results. And it seems to make even some of the dreary parts more fun because you can almost imagine it as a game you play against yourself. So I'm sold on TDD. I'd begun to realize the importance of having good estimates and honest, timely reappraisals before starting to read the book, but the author certainly drives home how very critical this is to a professional coder and the rest of the team. If you've programmed essentially for yourself (as a systems admin or database admin) but are moving toward true development, this is an essential book to read. It will show you bad habits to avoid and drive home the professional behavior that will earn you respect. I admit that is based on only about three months of experience in working with developers, but over the past two weeks (since I started the book) I'm sure that I sense a greater acceptance and respect.

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.

As with Clean Code, that other classic also by Robert C. Martin, The Clean Coder is one of these books I wish had fallen in my hands way before they did. There are many other books that teach you how to write good code - that is not the purpose of this book. Rather, Uncle Bob strives to show you how to be a good professional, and all that entails. If the concept makes you want to sneer, don't - there are lots of behaviors that we'd normally do which are not professional and hurt both your company as yourself. Have you ever said "yes" when pressed to commit to an unreasonable deadline? Pushed half-done work through? Given overly optimistic estimations that people thought of as deadlines? Felt forced to wade through a mess of (partly) your own making? Well, even if you haven't, odds are that you will at some time, as (sadly) every developer finds themselves at such situations at some point during this career. What this book aims to do is to help you identify these situations, explain why these are harmful and provide you with the tools to better respond to these. Oh, and of course, expect the usual useful insight on how to improve your programming practices. While Clean Code was a bit hard to read sometimes and made you stop every now and then, if only to get a better grasp of the concepts, this one feels so relatable that it reads in a breeze. What more can you ask for? Our craft would be a lot better if every programmer was given a copy of this before they started working. Or at the very least, I am certain that this book has helped me become a better professional and I expect its teachings will continue to do so.

I liked the way author correlated their past experiences which are relatively similar today. The idea of a professional software specialist and the professionalism is something we lack in the industry right now, this is needed for every small to large scale industry and I would point them this book to get a thorough understanding of what a professional does.

This book is a condensation and distillation of more than 40 years of industry experience. It is an amazing read. The book expresses the concept of professionalism in the clear, simple (not simplistic,) unapologetic style that Bob uses in all his writing. At a short 204 pages, you can read it in a weekend (like I did.) Having been involved in Agile (XP, XPish, ScrumBut) projects for several years and recently in the software craftsmanship movement, many of the concepts in the book were familiar. The chapters on Saying Yes, Saying No and Estimation really spoke to me. I have had many experiences where I have agreed to "try." Now I see the danger of that statement clearly. I have also had experiences where I have stayed firm on my estimates and been encouraged to feel as though I was not a committed team player. I now have additional tools to help me combat that feeling and take professional actions despite pressure (from management or the team) to do otherwise. For me, the most powerful section of the whole book is the commitments section of the Chapter 10 - Estimates. "Professionals don't make commitments unless they know they can achieve them. It's really as simple as that." Wow. I have reread that section several times.

I really enjoyed reading this book. It is great to watch someone else who went in same path as i am going right now. At sometimes you've got to question if Robert C. Martin is really right, but he describes his point of view. It doesn't mean it must be yours as well. The worst part of this book is preface. I don't know how this preface made it to the book, but it is saying that developers are not professionals because it's hard for them to stick to their promises and release dates. To me preface was something like making fun of developers and that's why i have found it offensive... I don't agree that professional developer should spare 8 hours/day working for his employer and then another 3 hours on his own study. If it should be so, the professional must be paid accordingly. I have not found anything about the other side of being professional - salary, payments... If it is your job to be responsible for every fault in the code and as book says you should pay if your fault makes an financial loss to your client, then you should also ask for adequate salary (which will cover your possible expenses for your failure). Anyway, fantastic book which i would recommend to anyone who want to get better at his job.

I've been interested in the notion of a professional programmer for a very long time, at least since my first reading of Gerald M. Weinberg's The Psychology of Computer Programming made me see the difference between amateur and professional programming. Heck, I like to think that I am a professional programmer. Then, along comes Bob Martin's The Clean Coder, containing "a lot of pragmatic advice in an attempt to answer questions such as": * What is a software professional? * How does a professional behave? * How does a professional deal with conflict, tight schedules, and unreasonable managers? * When, and how, should a professional say, "no"? * How does a professional deal with pressure? The subtitle, A Code of Conduct for Professional Programmers puts some significant weight on this book. And The Clean Coder is a pretty darn good book. For example, the first chapter is "Professionalism", and the first section is "Be Careful What You Ask For" with the following question: "What would happen if you allowed a bug to slip through a module, and it cost your company $10,000? The nonprofessional would shrug his shoulders, say 'stuff happens', and start writing the next module. The professional would write the company a check for $10,000!" Martin's comments on taking responsibility, and on saying "no" (and also on saying "yes" and meaning it) are spot on. His chapter on estimation is very good as well, emphasizing the distinction between an estimate and a commitment and introducing PERT estimates, which I seem to have managed to miss before. The list of good things about The Clean Coder goes on and on, including handling pressure, teams, and the development of a professional programmer from an apprenticeship. Further, the whole mass is leavened by Martin's war stories, dating back into the dim mists of antiquity and dealing with both his successes and failures. But... The book, which is not that big and a quick read, covers a wealth of advice at a high-level, with pointers to learn more. Many of those topics, as I have tried to point out above, are all over professionalism for the programmer. Things like responsibility, handling pressure, and mentoring. But there is other advice in the book which does not have the same pedigree. Some of it would appear to be a "nice-to-have" rather than a requirement. Then there are things that seem to be Martin's personal opinions. And then, there is stuff that is just bizarre. I don't want to get into the case for test-driven-development here. It works, well. (But then, so do code inspections, seemingly even better, and I have plenty of evidence for that. Yet it doesn't get the same press. And no, pair programming is not the same thing.) But the vast majority of working code in the wild was not produced by TDD. I can lay hands on more than a few very professional programmers who think unit tests are not worth their opportunity costs, to put it mildly. I will go as far as saying that unit testing is a good idea, and that TDD, in a lot of cases, gives me more confidence in my code. But I cannot go along with making it a requirement for professional programming. Appendix A, Tooling, has a nice list of useful development tools. "Tomato" time management is interesting. "When the heat is on, find an associate who is willing to pair program with you." Ok. I personally think "craftsmanship" is a good way to describe good programming. Most of the time, anyway. On the other hand, with all respect to Uncle Bob, if I tried, I could also track down a fair number of embedded and safety-critical software developers who regard the whole "agile" thing with a mixture of disbelief and horror. But what about this: "Much has been written about the hyper-productive state known as "flow." Some programmers call it "the Zone." Whatever it is called, you are probably familiar with it. It is the highly focused, tunnel-vision state of consciousness that programmers can get into while they write code.... "Here's a little hint from someone who's been there and back: Avoid the Zone.... Code written in the Zone may come out faster, but you'll be back to visit it more.... "One of the big benefits of pair programming is that it is virtually impossible for a pair to enter the Zone...." Let me just say that I don't have my copy of Mihály Csíkszentmihályi's books handy. But I do seem to recall that a reduced error rate is one of the definitive benefits of flow. Further, Martin's description of the Zone as "tunnel-vision" and "uncommunicative" directly contradict Csíkszentmihályi's description of flow in team sports. On the other hand, Martin's comments also contradict both the common description of pair programming's feel, and Martin's own comments about "focus-manna". And then there's the "Coding Dojo". Now look, I am a big fan of toy problems. They're fun, they're relaxing, working on one is roughly the equivalent of a situation comedy: everything gets wrapped up in 22 minutes. Better, they're good ways to try out something new, to explore a problem, or to isolate some issue so that you can examine it without getting lost in the surrounding weeds. But when Martin writes, "In 2005 I attended the XP2005 Conference in Sheffield, England. I attended a session with the name Coding Dojo led by Laurent Bossavit and Emmanuel Gaillot. They had everyone open their laptops and code along with them as they used TDD to write Conway's Game of Life.... "A programming kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. You aren't actually solving the problem because you already know the solution. Rather, you are practicing the movements and decisions involved in solving the problem." Well, after that, I've got nothin'. Sorry. In the end, Clean Coder has a lot of very good advice, a lot of good philosophy about programming professionalism. It also has many entertaining stories. But I, as a (possibly delusional) professional programmer, just don't see it as a grand manifesto.

-

Another great book from Uncle Bob. This time it is not about the program but the programmer. I think every programmer should read this book very early in their career. What Bob writes about professionalism is spot on.

I'm about halfway through and already its one of the most meaningful books in my career. It tackles a lot of the non-code issues in programming, such as being consistent on deliverables and communicating effectively. No matter how good of a coder you are, following the advice in this book will make you a better professional and more employable. Absolutely worth every penny.

This book is perfect for those who want to see and learn tips to improve as a professional, an excellent book for my taste.

Non troverete una riga di codice in questo libro, ma molte indicazioni su come un professionista si formi, pianifichi, reagisca alle emergenze e in generale si comporti. Per la serie "allora non ero pazzo io".