Biggest takeaways from each chapter of The Clean Coder by Robert C. Martin

I just finished a quick, instructive, and entertaining book about being a professional software developer: The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin (aka, Uncle Bob). Unlike his other books The Clean Coder is not about code function and design, rather, it outlines the characteristics and day-to-day conduct that differentiate a regular software developer from a professional software developer.

The book depicts a person who is an ideal, asymptotical goal of perfection; not something any one person can achieve in reality (someone who writes TDD 100% of the time, tests everything, sleeps 8 hours per night, refactors mercilessly, says No and YES at all the right times, spends 20 hours a week outside of work on personal coding development, warms up and cools down with coding challenges each day, drinks the ideal amount of caffeine, cares equally about the business goals as she does about technical goals, reads science fiction, etc).

Some of the examples that Uncle Bob shares are not the best examples (30 years ago were different times) and he goes into a lot of detail about how they got things done back then, but the main idea still comes through clearly in each chapter. I also don’t agree fully with some of his opinions on weighing TDD methods over working/functioning code that meets a deadline (although, in an ideal world this would be a nice-to-have).

That all being said, I can see a lot of ways projects, teams, and personal productivity could be improved from what I learned while reading. I’m going to go ahead and add this to my Books I wish I read when I first became a professional software engineer list.

Here is a summary of the main ideas and concepts I took away from each chapter of The Clean Coder:

Chapter 1: Professionalism

• Do no harm to function or structure of the code: don’t introduce bugs, make sure you code is tested. If it can’t be tested, write it in a way that is testable. If testing is too cumbersome, automate the testing.
• A true professional knows that delivering function at the expense of structure is a fool’s errand.
• Every time you look at a module you should look for ways to make small, lightweight changes to make it better. AKA, leave code better than you found it even if you didn’t write it.
• Your career is YOUR responsibility, not your employer’s. You owe your employer 40 hours a week, make sure you put in an extra some hours for yourself (reading, practicing, learning) to hone your skills and make sure you are developing in the areas you want to be developing in.
• Know your field and know it well. Know design patterns and principles, methods, practices.
• Practice. Practice. Practice. True professionals keep their skills sharp and ready. Musicians don’t get better by performing (doing your job), they get better by practicing (outside of work). That same rule applies to engineers.

Chapter 2: Saying NO

• True professionals have the courage to say no to their managers. Pursue and defend your objectives as aggressively as you can. If you know full well that getting the job done by X date is not doable, but you still say “I’ll try” then you are not doing your job right.
• Your manager is counting on you to defend your objectives and not just agree with everything that she says. Be assertive. Both you and your manager need to get to the best possible outcome through negotiation.
• Conversations might be adversarial and uncomfortable — but that’s all in the pursuit of a mutually agreeable solution and the best possible outcome (the ultimate goal).
• When it comes not being able to meet the deadline, the WHY is less important than the FACT that you can’t meet it.
• Make sure you have documentation (memos) for high stake deliverables/situations (CYA)

Chapter 3: Saying YES

• Say it, mean it, do it.
• Recognize lack of commitment phrases and words in others and yourself. They include: “need”, “hope”, “Let’s see if we can get this done...”.
• The secret ingredient to recognizing what a sincere commitment sounds like is to look for phrases that resemble “I will do something… by this certain date…”
• If you rely on someone else to get your job done, do what you can to get what you need to move forward. Don’t let them be a blocker.
• Bring up blockers or red flags as soon as they come up — communicate.
• Professionals are not required to say “yes” to everything that is asked of them. However, they should work hard to find creative ways to make the “yes” possible (e.g., reducing scope)

Chapter 4: Coding

• Be prepared to code for the day. Warm up with some short coding challenges. Cool down with some too.
• Don’t write code at 3 am or when you are preoccupied with something personal. You’ll have to rewrite it later (or worse, live with it).
• Spend personal time before work trying to resolve or mitigate personal issues or demands so you can focus your mental energy on being a productive problem solver at work.
• Be prepared to be interrupted and help someone — it’s the professional thing to do.
• When you hit writer’s block make sure you are sleeping, eating, and exercising enough. Additionally, read science fiction (or another form of creative consumption other than surfing the internet or watching TV). Lean on other creative consumption outlets to help keep you creative on the job (I happen to like science fiction so I don’t mind this advice).
• Save yourself time from debugging and practice TDD. Also, debugging is technically considered productive coding too! Don’t discredit debugging as ‘non-coding’ work.
• Software development is a marathon — not a sprint. Conserve your mental energy during the day.
• “Hope” will get you into trouble (“I hope to have it done by…”). Don’t hope. Be direct about your timelines and realistic expectations. If you must, use an estimate/range.
• Ask for help and ask to give help (mentor).

Chapter 5: TDD

• Good tests function like good documentation.
• TDD is a discipline that enhances certainty, courage, defect reduction, documentation, and design.
• It’s professional to use TDD.

Chapter 6: Practicing

• It is not your employer’s job to keep your skills sharp for you. That onus is on YOU.
• Practice coding outside of work by doing kata. Coding kata means simulating the solving of some programming problem that you should already know the solution to; you are just practicing movements to drive problem/solutions pairs into your subconscious.
• Other ways to practice: take on pro-bono work or a pet project, contribute to open source.
• Practice is something you do when you aren’t being paid.

Chapter 7: Communicating

• Professional developers remove ambiguity from requirements.
• Acceptance tests should be automated and written by the business for the business.

Chapter 8: Testing

• Teams should have a testing strategy defined.
• See the automation test pyramid.

Chapter 9: Time Management

• Professional software developers are diligent in the management of their time.
• Meetings are necessary AND huge time wasters.
• You do not have to attend every meeting — be careful about which ones you decline and choose to attend. Your responsibility is to YOUR PROJECT first. You should work with a manager about how to reduce meetings from your schedule.
• Politely leave a meeting if it is not worth your time.
• Meetings should have a clear agenda and if they steer away from that agenda then someone should table the actual meeting agenda for another time.
• Daily stand up should be 20–30 seconds per update; what you did yesterday, what you are working on today, and any blockers.
• IPM = Iteration planning meeting where a team selects backlog of stories for the next iteration (I know this already, but didn’t know it my first day on the job).
• Try time-boxing and/or tomato timer idea: Use a 25 minute timer and focus on the task at hand during that 25 minutes. If any interruptions come up, defer them until your time is up. Once your timer is up, address all the issues that came up and take a quick break. Then, restart the timer and continue to focus. Track your work by how many 25 minute tomato timers you can get through in a day.
• Professionals evaluate priority of each task, disregarding personal fears and desires, and execute in priority order.

Chapter 10: Estimation

• You are honor-bound to decline something you cannot commit to. Commitment is about certainty.
• Professionals know the difference between estimates and commitments.
• Estimates are just guesses. Estimates are ranges (not exact numbers).
• Avoid the word “try”. It’s a loaded term.
• Something to look into is a method like PERT to get a better estimate.
• Professional software developers are very careful to set reasonable expectations despite the pressure to try to go fast.
• Estimating methods: wide band delphi, flying fingers, planning poker.

Chapter 11: Pressure

• A professional developer is calm and decisive under pressure. As pressure grows, she adheres to disciplines knowing that they are the best way to meet the deadlines and commitments pressing on her.
• Under pressure? Be sure to manage your commitments, follow disciplines, and keep code clean, communicate, and ask for help.

Chapter 12: Collaboration

• Programmers have difficulty working closely with other programmers. That’s no excuse, though. Being a developer means working with people.
• The team owns the code, not the individual
• Professionals pair (and have good pairing habits).
• Pairing is a great way to share knowledge so that people don’t end up in knowledge silos.
• All team members should be able to play another team members’ position in a pinch and should know each other’s code.

Chapter 13: Teams and projects

• Strive to have a “gelled” team. A gelled team is one that forms relationships, collaborates, and learn each other’s quirks and strengths.
• Gelled teams can work miracles. They plan together, solve together, and get things done.

Chapter 14: Mentoring, apprenticeship, and craftsmanship

• You can’t learn the skill of being a craftsman (aka, a professional) from school; you learn that from mentoring and apprenticeships.