After almost 5 years of working professionally as a software developer, I thought I had learned enough of what a true professional programmer should do. I’m not a huge fan of reading. Nevertheless, I heard good things about The Clean Coder by Robert C. Martin, aka Uncle “Bob”. In fact, I read his most popular book called Clean Code a few years ago, in which I learned concepts I still use daily in my career.
One of the things you don’t learn at school is how to be professional. In fact, learning how to be a professional is a concept you learn mainly by doing two things:
- Observing: Most likely, your main influencers in your life teaching you how to behave professionally are your parents, especially when you were growing up and you observed how they behaved not just when they were working, but any kind of situations of life.
- Living: The more you live, the more experiences you get. Life constantly teaches you something. Every failure you have experienced is a learning process.
I thought that by following these two things I was behaving professionally as a software developer.
However, I didn’t expect to find a book that would show me unprofessional behaviors as a professional programmer. Why? Because the author once had thoughts and behaviors similar to mine, and similar to several dedicated programmers who passionately put thousands of hours writing code to make software work.
Although you don’t need to agree with all of Uncle Bob’s concepts shared in his book, I certainly believe the quality of content in that book is worth reading at any point of your career. In this case, I will share the takeaways I got from reading The Clean Coder:
Table of Contents
Ch 1. Professionalism
- Programmers want software to work, not to create bugs. Be responsible for your imperfections.
- Automate tests by implementing Test Driven Development (TDD).
- Continuously shape and mold the software. In other words, constantly work on your code, constantly refactor it.
- Professionals spend time caring for their profession: Dedicate at least 20 hours outside of work to practice.
- Take responsibility to mentor juniors.
Ch 2. Saying No
- You are not supposed to do what your boss says all the time.
- Programmers will pursue and defend their objectives as aggressively they can.
- A team player is not someone who says “yes” all the time.
- Saying “try” is a commitment to succeed. Be careful when you say “try”.
Ch 3. Saying Yes
- When you say yes, you commit to do it, and you mean to do it.
- Notify about red flags as soon as possible.
- You’ll be taken seriously when you do, as fully complete without bugs, what you committed to do.
- Don’t use shortcuts in the development process, whether it is to avoid refactoring, not writing tests, or omitting full regression suites to speed up development. Stepping away from your disciplines will slow you down.
- Professionals know their limits. Don’t go beyond them if you know them.
Ch 4. Coding
- Customer requirements don’t solve customer’s problems.
- Your code must be readable.
- Don’t write code when you are tired. It will be your worst code.
- Professionals don’t have to be heroes and code for a crazy amount of hours.
- Listening to music while coding doesn’t really help your concentration.
- Pace yourself: Take care of your body.
- You won’t code faster under pressure. You can’t make yourself solve problems faster.
- Collaborate, even if you did intend to join the programming world to avoid people.
Ch 5. Test Driven Development
- The only way to test all of your code is by exercising TDD.
- You can still write bad code even if you write your tests first.
- Ship latest changes without sweating if all tests are passing.
Ch 6. Practicing
- Practice during your off-work hours. Be ready to combat during working hours.
- Practice is what you do when you aren’t getting paid.
Ch 7. Acceptance Testing
- Business people state what they believe. Programmers build what they believe the business described.
- Things appear different on paper than they do in a working system.
- Done means all code written, all tests passed, QA and stakeholders have accepted. Done.
- The purpose of a test is not to test but to document.
- Automated acceptance tests remove ambiguity.
Ch 8. Testing Strategies
- Programmers’ objective is that QA finds nothing wrong.
- Implement integration tests to test how well the assembly of components works together.
Ch 9. Time Management
- When the meetings get boring, leave.
- Programming requires extended periods of concentration and focus, avoid distractions and interruptions for longer amounts of time.
- Messes slow you down, but don’t stop you. Clean them as soon as they are recognized.
Ch 10. Estimation
- Business people view estimates as commitments. Developers view estimates as guesses.
- Break large tasks into smaller tasks and estimate them independently.
- Do not make promises you can’t keep.
Ch 11. Pressure
- The best way to meet the deadlines and commitments is by adhering to your code principles.
- Enjoy your career by doing it well, not by doing it stupidly.
- Stay calm under pressure by avoiding situations that cause pressure.
- Don’t be tempted to create a mess in order to move quickly.
- Follow disciplines that you feel comfortable following in a crisis.
- Sleepless nights won’t help you get done any faster.
Ch 12. Collaboration
- Programmers who don’t let other programmers see their code is a recipe for disaster.
- The team must own the code, not individuals.
- Share knowledge by doing pair programming.
- The team does not work better when you work alone.
Ch 13. Teams and Projects
- Teams are hard to build and hard to gel.
- Gelled teams will get things done.
Ch 14. Mentoring, Apprenticeship, and Craftsmanship
- Companies lose a lot of money due to the inadequate training of their software developers.
- There are 3 types of developers: Masters: 10+ years of experience, Journeymen: ~5 years of experience, and Apprentices/Interns: 1 year of experience.
- Craftsmanship is the mindset held by craftsmen. If you want to be a professional, be a craftsman.
- School doesn’t teach the discipline, practice, and skill of being a craftsman.
My favorite chapters were chapter 2 – Saying No, chapter 4 – Coding, and chapter 11 – Pressure. The reason is because many of us are constantly committing to delivering features within impossible to meet deadlines. For some reason we think we can get superpowers overnight and become Flash to be able to type the keyboard faster, or to not sleep enough hours because any hour not spent coding is precious and valuable time you could have made progress, especially when the timeframe to deliver is lacking enough time to correctly develop all the features.
Knowing we don’t have to be heroes is a wiser thought when there’s too much uncertainty or pressure for completing projects that weren’t supposed to even be started at the beginning. Working hard doesn’t mean to put in more hours of code. Working hard is to fully dedicate the allocated hours of work, generally 8 per day, to write quality code. Work hard on mastering your skillset by becoming more effective and efficient.
One of the topics in which readers will have a different position is to dedicate an additional 20 hours a week to practice your skillset, especially when not everyone has that amount time because of whatever reason. Also, practicing TDD always has several benefits when it comes to delivering better and documented code. However, not all businesses count with either big budgets or long timeframes often required for the good practice of TDD.
All in all, The Clean Coder is a book I strongly recommend reading. Whether you are in the beginning of your journey as a programmer or a seasoned programmer, you will relate with many of the topics mentioned in this book, especially when the author has been in the industry for over 40 years.
