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.
Loading your book clubs
There was a problem loading your book clubs. Please try again.
Not in a club? Learn more
Join or create book clubs
Choose books together
Track your books
Bring your club to Amazon Book Clubs, start a new book club and invite your friends to join, or find a club that’s right for you for free.
Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required.
Read instantly on your browser with Kindle for Web.
Using your mobile phone camera - scan the code below and download the Kindle app.
Customers who bought this item also bought
Page 1 of 1 Start overPage 1 of 1
From the Publisher
From the Preface of "Clean Architecture"
“…The rules of software architecture are the rules of ordering and assembling the building blocks of programs. And since those building blocks are universal and haven’t changed, the rules for ordering them are likewise universal and changeless.
But one thing has changed: Back then, we didn’t know what the rules were. Consequently, we broke them, over and over again. Now, with half a century of experience behind us, we have a grasp of those rules.
And it is those rules—those timeless, changeless, rules—that this book is all about.”
— Robert C. "Uncle Bob" Martin
|
|
|
|
|
|
|---|---|---|---|---|---|
| Clean Code: A Handbook of Agile Software Craftsmanship | The Clean Code: Practical Advices for the Professional Programmer | Clean Craftsmanship: Desciplines, Standards, and Ethics | Clean Agile: Back to Basics | Clean Architecture: A Craftsman's Guide to Software Structure and Design | |
| Best agile practices of cleaning code “on the fly” Software Craftsmanship. | Endure and succeed amidst swirling uncertainty and nonstop pressure. | Picks up where Clean Code leaves off, outlining additional ways to write quality and trusted code you can be proud of every day. | A clear and concise guide to basic Agile values and principles. Perfect for those new to Agile methods and long-time developers who want to simplify approaches for the better. | Direct, no-nonsense answers to key architecture and design questions. | |
| "It is the best pragmatic application of Lean principles to software I have ever seen in print." —James O. Coplien, Founder of the Pasteur Organizational Patterns project | “Some technical books inspire and teach; some delight and amuse. Rarely does a technical book do all four of these things.” — George Bullock | ". . . [A] timely and humble reminder of the ever-increasing complexity of our programmatic world and how we owe it to the legacy of humankind--and to ourselves--to practice ethical development.” — Stacia Heimgartner Viscardi, CST & Agile Mentor | “What is in the world of Agile development is nothing compared to what could be. This book is Bob’s perspective on what to focus on to get to that ‘what could be.’ And he’s been there, so it’s worth listening.” — Kent Beck | "A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than as a frozen artifact." — Kevlin Henney |
Pick Up Where Clean Code Leaves Off
"As software developers, we have to continually solve important problems for our employers, customers, colleagues, and future selves. Getting the app to work, though difficult, is not enough, it does not make you a craftsman. With an app working, you have passed the app-titude test. You may have the aptitude to be a craftsman, but there is more to master. In these pages, Bob expresses clearly the techniques and responsibilities to go beyond the app-titude test and shows the way of the serious software craftsman."
— James Grenning, author of Test-Driven Development for Embedded C and Agile Manifesto co-author
About the author
Follow authors to get new release updates, plus improved recommendations.
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
Reviewed in the United States on April 15, 2016
Reviewed in the United States on September 23, 2011
Reviewed in the United States on October 7, 2023
Reviewed in the United States on August 18, 2023
Top reviews from other countries
Client Kindle
Amazing book. I'd say it's a must for those who call themselves professionals.
Reviewed in Brazil on August 20, 2021
Harika B
Must read for every software engineer who wants to improve themselves to software "Professional"
Reviewed in India on December 19, 2020
