Book SummaryThe Clean Coder, by Robert C. Martin

1-Page Summary1-Page Book Summary of The Clean Coder

In The Clean Coder, expert developer Robert C. Martin explains how to be a programming professional—an honorable, reliable employee who produces quality work (or takes responsibility for the rare times she doesn’t). Professionals’ most important responsibility is to meet their employer’s needs.

In this summary, you’ll learn about six qualities and skills of a professional coder and how to develop them.

Quality #1: Commit to Your Professional Development

The first quality of a professional is a commitment to professional development. The hours you put into your day job rarely contribute to your professional development because at work, you often perform tasks and skills you already know how to do. Therefore, to be a professional, you should spend 20 hours per week of personal time on improving your programming skills and learning new ones.

• (Shortform example: If you’re a front-end web developer by day, you won’t have any opportunity at work to practice working the back end, so you’ll need to learn those skills on your own time.)

Use these hours to:

• Improve your existing skills. Contribute pro bono to open source projects and do coding exercises like kata, ping-pong, or randori. Aim to get the unconscious part of your mind to recognize a problem and your body to instinctively react to it (for example, by hitting a particular combination of keys). This leaves the rest of your mind free to focus on strategy and problem-solving.
• Learn new skills. Learn about the industry’s history, new developments, and your customer or employer’s field. Additionally, develop your error sense (becoming aware of mistakes as you make them) and humility (accept you’ll make mistakes, and don’t attack others for theirs).

Quality #2: Practice Discipline

Professional quality #2 is discipline—a collection of rules and standards around the act of coding. Everyone’s discipline is personal and unique, and in this section, Martin shares his rules as inspiration.

Rule #1: Avoid doing damage, or when you can’t, take responsibility. To avoid doing damage:

• Personally and regularly test all of your code. Before you release your code to anyone, including Quality Assurance, make sure you know that it works.
• Learn from bugs so you can avoid making the same mistake in the future.
• Clean up bad code. When you come across something you know how to improve, refactor it.

Rule #2: Don’t code while you’re tired or worried. if you’re not in a mental space in which you can concentrate, you’re going to make mistakes and have to throw out most of your work. If you’re tired or worried:

• Disengage and recharge. Once you’ve used up all your focus, you need to recharge by disengaging and spending at least an hour doing something that doesn’t require focus. For example, you might go for a drive, exercise, or take a nap.
• Boost your focus reserves and use them wisely. Get enough sleep, use caffeine only in moderation, and pace yourself. When you have focus, code, when you don’t, do other work that’s less mentally taxing.
• Address distractions. If you’re worried about something, part of your brain will be occupied with the worry instead of thinking about your code. Devote some time (often an hour) to addressing the worry—making some progress can reduce your anxiety enough to let you work.

Rule #3: Don’t wallow in writer’s block. When you’re feeling stuck, try the following techniques to get past the block:

• Increase your content consumption. Consuming creative content (like reading sci-fi novels) will help you output creativity—inspired by someone else’s work, you’ll want to create your own.
• Pair program. Working with someone else will nearly always refresh you. Martin feels a physiological change when pair programming.

Rule #4: Avoid or minimize time pressure. The best way to deal with pressure is to avoid it. To do this:

• Adhere to your rules. You’ll be most efficient if you don’t break things, don’t get stuck behind writer’s block, and so on.
• Use your crisis behaviors all the time. In a crisis, you’ll use the most effective and efficient method of doing something. If you use your crisis methods all the time, you’ll be as efficient as you are in emergencies all the time.
• Say no to unreasonable deadlines. See Quality #3 for more on this.
• Watch out for manipulative client behaviors. If a client describes the project as simple and easy, fails to discuss all required features, or pushes deadlines, you might want to avoid working with them.

No matter how well you employ the above techniques, you’ve inevitably going to encounter pressure. When you are under pressure, you should:

• Stay calm. Getting stressed and rushing will only do damage, which will ultimately slow you down because you’ll have to go back and fix things.
• Exaggerate your rule-following. For example, if your normal workflow involves refactoring, refactor more than usual.
• Talk to your coworkers and pair program. Pair programming produces higher-quality code faster—your partner will help you focus, stay calm, and see the whole project.

Rule #5: Avoid the “zone” when you’re working. The “zone” is a state of mind that makes you feel focused, productive, and invincible. In reality, you’re not being more productive—the zone is just a meditative state in which parts of your brain shut off. You’ll write more code, but because you’ve got tunnel vision, you’ll probably have to revise what you’ve written so it fits into the larger structures. If you feel the zone approach, arrest its onset by taking a break or pair programming (you can’t get hyper-focused on your code if you have to talk to someone.)

Rule #6: Be careful with music. Some people find music helps them concentrate; for others, it pushes them into the zone or distracts them.

**Rule #7: Finish properly....

The Clean Coder Summary Chapter 1: Quality #1—Commit to Your Professional Development

In The Clean Coder, expert developer Robert C. Martin explains how to be a programming professional—an honorable, reliable employee who produces quality work (or takes responsibility for the rare times she doesn’t). Professionals’ most important responsibility is to meet their employer’s needs.

Many people (including developers) don’t consider developers professionals, and this is partly because developers don’t act like professionals. Martin certainly didn’t, when he started his career—he missed deadlines, didn’t test code before releasing it, and was such a bad leader he got two people working under him fired. In this book, he shares the lessons learned the hard way, in the hopes that he can help you avoid making some of the same mistakes.

He’ll teach you about the six qualities and skills of a professional and how to develop them:

1. Commitment to professional development
2. Discipline
3. Honesty (around estimates and deadlines)
4. Communication (via testing)
5. Time management
6. Collaboration

And at the end, in an appendix, you’ll learn about some of the tools and programs that will help you master the skills and qualities.

Note: The Clean Coder isn’t a...

The Clean Coder Summary Chapter 2: Quality #2—Practice Discipline

In the last chapter, we learned about the first quality of a professional—a commitment to learning. The second quality of a professional is discipline—professionals adhere to personal rules and standards around the act of coding. The rules aren’t always about the actual code; sometimes they’re about attitude and behavior while working.

Everyone’s rules will be different. In this chapter, Martin shares what works for him in case you’d like to adopt it, but he also encourages you to reflect on what else might work for you.

Rule #1: Avoid Doing Damage

The first rule is to avoid doing damage, and if you do create damage, to take responsibility for it by apologizing and learning from the mistake.

A software developer can damage two things:

1. The working of the software. You damage the working by making a change that creates a bug that breaks the software. To avoid damage and take responsibility:

• Personally and regularly test all of your code. Before you release your code to anyone, including Quality Assurance, make sure you know that it works. (Relying on QA to find problems is expensive, causes delays, and is lazy.) If you feel you don’t have time...

Shortform Exercise: Follow Rule #2

Martin gives suggested rules for professional conduct, and rule #2 is to avoid coding when worried or tired.

If you start to feel tired at work, Martin advises you to take a break and recharge. What recharging activities appeal to you and why? (Walk, nap, listen to a podcast, and so on.)

The Clean Coder Summary Chapter 3: Quality #3—Be Honest About Deadlines

In the last chapter, we looked at the discipline and rules all professionals adopt. The next quality of a professional is honesty, especially about estimates and deadlines.

Whenever you’re programming something for someone, they always want to know when it will be done. Most of the time, you won’t know exactly how long something will take, so you’ll provide an estimate instead of a commitment (guarantee). Estimates have the following qualities:

1. They aren’t promises (though businesses often interpret them as such, which is why there’s often conflict between programmers and businesspeople).

2. They aren’t single numbers—they’re probability distributions. They factor in the following three numbers:

• Best-case. If everything goes right, you’ll be finished in this amount of time. This number should be very optimistic—there’s only a 1% chance that you’ll make this number.
• Nominal. This is the amount of time you think is most likely.
• Worst-case. If everything goes wrong, you’ll be finished in this amount of time. This number should be very pessimistic—there’s only a 1% chance that this is how long the task will take you.

Missing...

Shortform Exercise: Estimate Using the PERT Method

Program evaluation and review technique (PERT) is a method for estimating how long a task will take as a range.

Think of a task you’re currently working on. What are your best-case, nominal, and worst-case estimates for how long it will take you to do the task?

The Clean Coder Summary Chapter 4: Quality #4—Communicate via Testing

In the previous chapter, we looked at the third quality of professionals: honesty. Next, we’ll look at the fourth: communication, which is best done via testing.

Tests ensure that a system works, but that’s a happy bonus, not their main purpose. The most important purpose of a test is to communicate, specify, and document how a system is supposed to work and how it actually works.

In this chapter, we’ll first look at acceptance testing, which is the main type of testing used for communication. Then, we’ll look at how acceptance tests fit into the broader discipline of testing.

How to Communicate Effectively

When clients speak with programmers, there are often miscommunications, especially about system requirements. This is because the businesses describe to programmers what they want (sometimes ambiguously), and the programmers estimate and build what they understand from the description (sometimes incorrectly). Ambiguity comes from two sources:

1. Business stakeholder disagreements. If stakeholders can’t agree on how something should work, sometimes, instead of addressing this, they’ll write a vague description that everyone can agree on. Then, a...

The Clean Coder Summary Chapter 5: Quality #5—Manage Your Time Well

In the last chapter, we looked at how professionals use tests to both communicate and ensure their code works. Now, we’ll look at the fifth quality of professionals: They manage their time well.

There are three techniques professionals use for time management:

Technique #1: Attend Meetings Strategically

Meetings take up a lot of time and are expensive—they require renting a location and paying for the time of the attendees. Therefore, professionals strive to make the best use of meetings, which they do by avoiding the ones that waste their time and ensuring the valuable ones are efficiently run.

Avoiding Time-Wasting Meetings

There are two strategies to avoid wasting time in meetings:

Strategy #1: Don’t Agree to Attend

You should only go to a meeting if it meets the following criteria:

1. You’ll get information that’s important to your current project.
2. The meeting is about an interesting but not urgent topic, and you have the time to attend.
3. You can help someone else. (Keep in mind that your first loyalty should be to your own projects, so if attending a meeting would contribute to someone’s project but harm yours, don’t go).
4. The meeting...

Shortform Exercise: Reflect on Meetings

Meetings can be critical or time-wasting, so you must be strategic about how you approach them.

Think of an upcoming meeting you’ve been invited to. Does it meet the criteria for being worth your time? (It will give you important information; it’s about an interesting topic; it will allow you to help someone; it has an agenda, schedule, and goal?) How do you know?

The Clean Coder Summary Chapter 6: Quality #6—Collaborate

In the previous chapter, we looked at the fifth quality professionals possess: time-management skills. Now, we’ll look at the final quality: the ability to work with others. First, we’ll look at teamwork, then mentoring.

Teamwork

Professionalism involves doing whatever produces the best possible work, and the best work is achieved via collaboration. (Even if you’re one of the rare people who works best alone, you hamstring your team’s work—and as a result, hurt your employer—when you refuse to collaborate.)

Putting Together a Team

There are two approaches to putting together teams:

1. Build the team around a project. Assign programmers, analysts, testers, and a project manager to work on a project for a percentage of their time. The members can belong to other teams working on other projects at the same time.

2. Start with the team. Create a team of programmers, analysts, testers, and a project manager, and then assign the team to work on multiple projects together. Usually, this kind of team consists of 12 people: one project manager, two testers, two analysts, and seven programmers. Here are their jobs:

• The project manager keeps track of...

The Clean Coder Summary Appendix: Programming Tools

In the previous six chapters, we discussed the qualities and skills of professionals. In this appendix, we’ll explore some of the programming tools you can use as you work toward professionalism.

Source Code Control/Version Control Tools

There are two main types of source control tools, open source and “enterprise.” Open source tools are usually better than “enterprise” ones because open source tools are built by developers (who know what features other developers need). Enterprise tools, on the other hand, are usually aimed to appeal to business people, and often they have extraneous features but lack the features developers require, especially speed.

Martin recommends the following open-source tools:

• Subversion if you don’t need to branch
• git if you do need to branch. git allows developers to keep a local copy of the entire project and then merge copies later.

If your company has an enterprise system, you can still use an open-source system—use the open-source system during iterations, and check the source code into the enterprise system at the end of iterations.

Integrated Development Editors (IDEs)

IDEs all have their pluses and...