Some time ago, I discovered a very interesting page on InformIT called the eBook Deal of the Day, where you can buy IT ebooks for only $9.99. Every 24 hours (or sometimes slightly longer), they change the title available at this amazing price, so it is worth checking periodically or following them on Twitter.
One day, I noticed they were selling Robert C. Martin’s book, The Clean Coder. Since it was so affordable and I was already impressed by his previous work, Clean Code, I ordered an electronic copy without the slightest hesitation and started reading.
My Opinion
This title joins my list of “must-read” books for any developer aspiring to improve. It illustrates how we, as developers, can act as professionals and, as a result, be perceived and treated as such. Drawing on his own experience—did you know he has been a programmer for over 40 years?—Uncle Bob shows us how to improve our habits, communication, and collaboration skills to become more valuable to our teams, our companies, and our clients.
Below are the main takeaways I found most impactful.
Chapter 1: Professionalism
In the first chapter, we learn that being a professional comes with responsibilities. We must take ownership of our actions and cannot take potential mistakes lightly. Every error we make has serious implications; for example, a client could lose trust in the company, or a software crash could cause significant financial loss. As professionals, we should focus not only on adding new features but also—perhaps primarily—on ensuring we do no harm to the existing system.
“You must be able to make changes without exorbitant costs.”
Our code and architecture must remain flexible to ensure that future changes are as painless as possible.
Chapters 2 and 3: Saying “No” and “Yes”
These chapters discuss the importance of honest communication. We shouldn’t be afraid to state that adding a feature is impossible within a given timeframe so that the team or project manager can react properly. The earlier we say “No,” the better. However, we should always try to find a way to say “Yes”—perhaps by removing less important elements or postponing another feature to a later iteration.
“Slaves are not allowed to say no. Professionals are expected to say No.”
The worst thing a developer can say when being pushed to meet an impossible deadline is, “I will try.” This implies that you weren’t working at full capacity before and that “trying harder” will magically bridge the gap. By saying “I’ll try” without a firm “Yes,” you unintentionally make a commitment you cannot keep. In professional estimation, there is no “trying.”
Chapter 4: Coding
In this section, Uncle Bob argues that the famous state of mind called “The Flow” or “The Zone” is not as beneficial as most people think. While it allows a developer to stay focused on a single task, it prevents them from seeing the “big picture” or the context of their work. This can lead to bugs, code duplication, and architectural misunderstandings. A great way to avoid getting stuck in the “Zone” is Pair Programming, where you frequently switch between being the “Driver” and the “Navigator.”
“Creative output depends on creative input.”
Programming is a creative act. To increase creativity, we must feed our minds with creative ideas from outside our field. For Uncle Bob, this means science fiction; for others, it might be a thriller or poetry.
Chapter 12: Collaboration
Soft skills and communication are just as important as technical skills. Most projects today are developed by teams with diverse personalities rather than lone wolves.
“It’s good to be passionate about what we do. But it’s also good to keep your eye on the goals of the people who pay you.”
The key takeaway here is that professional developers must cooperate effectively. We need to think beyond ourselves and consider the needs of our company and our clients. At the end of the day, they are the ones paying the bills.
Valuable Ideas and Quotes
- “Hope is a project killer.” If your estimate says a task takes two weeks and the demo is in five days, don’t “hope” to finish. Inform stakeholders immediately so the deadline can be managed.
- “An estimate is a guess, not a commitment.” We are often expected to do things we’ve never done before and predict exactly how long they will take. We should educate managers that an estimate is a range of probability, not a hard number.
- “Projects should be fed to teams, not teams to projects.” It is harder to build a cohesive team than it is to start a project. Instead of forming and disbanding teams for every new project, companies should keep “gelled” teams together and find projects for them to work on.
Summary
These quotes are my personal favorites, but I strongly recommend reading the book yourself. You will likely find your own set of insights. Learning from Uncle Bob’s decades of experience is one of the fastest ways to become a better developer.
What about you? How do you handle impossible deadlines or “The Zone”? Let me know in the comments!
