There are some technical bits here and there but the majority of the content deals with what one needs to do to become a “professional” (the word Uncle Bob stressed a lot in the book as the subtitle of the book is “A Code of Conduct for Professional Developers”) developer.
For more coding oriented content, you might want to refer to his previous book, Clean Code, which was also a phenomenal book.
Here is the table of contents.
2. Saying No
3. Saying Yes
5. Test Driven Development
7. Acceptance Testing
8. Testing Strategies
9. Time Management
13. Teams and Projects
14. Mentoring, Apprenticeship, and Craftsmanship
Uncle Bob starts by defining what “Professionalism” is.
Then he describes the situation when a professional should say “Yes” and “No”. When someone constantly asks you to do “try” something, you don’t give up and say that you will “try”, which is same as admitting that you can get it done within said time constraint. Uncle Bob argues that saying “Yes” when you know that you can get something done within the time constraint put on your project is unprofessional. You should say “No” and be consistent about it.
As another renowned engineer Ken Beck did in Extreme Programming Explained, the Clean Coder dedicates a chapter on Test Driven Development (TDD). TDD is something one does not abandon during crunch time. One should actually do more of it, Uncle Bob writes because doing so would prevent a developer from writing bad code, which would cause more debugging time thus slowing down the progress.
When Kent Beck stressed the importance of pair programming, I just didn’t buy it. But when Uncle Bob mentioned that one would code in pairs during the time of crisis, why would not one want to do a pair programming during normal time, it struck me hard. I often ask my coworkers to look at my code when pressure is cooking and I can’t see what’s wrong with my code.
How should a professional develop her/his skills? Uncle Bob compares professional development with what martial arts and other professionals in different fields do; Practicing. He brings up many concepts such as
He then moves toward how to do testing and how it should be done.
As I mentioned before, one should not say “Yes” when you cannot get something done in time. How do we know that we have enough time or not before saying “Yes”? Uncle Bob talks about how to manage time and make estimations to find out when to say yes or no.
The rest of chapters are dedicated on how to deal with pressures and work with other developers on a project.
I had a great time reading the book as I was reading hours without noticing. If you wonder about how to conduct and grow as a professional developer, this is the book for you.