This article is an excerpt from the Shortform book guide to "The Clean Coder" by Robert C. Martin. Shortform has the world's best summaries and analyses of books you should be reading.
Like this article? Sign up for a free trial here .
What is Robert C. Martin’s The Clean Coder about? What qualities, according to the author, distinguish a professional developer?
In his book, 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). A professional’s most important responsibility is to meet their employer’s needs.
Below is a brief overview of The Clean Coder: A Code of Conduct for Professional Programmers by Robert C. Martin.
The Clean Coder: A Code of Conduct for Professional Programmers
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.
In his 2011 book The Clean Coder: A Code of Conduct for Professional Programmers, you will learn about the six qualities and skills of a professional programmer and how to develop them:
- Commitment to professional development
- Discipline
- Honesty (around estimates and deadlines)
- Communication (via testing)
- Time management
- Collaboration
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.
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. Completely finish all tasks before declaring them “done” and define “done” as “passed all tests” (for more on tests, see Quality #4). Don’t accept partial completion for any reason, including if you’re short on time.
Rule #8: Give and accept help. Programming is so hard it requires more than one brain. When people ask you for help, always give it, and if someone appears to be struggling, offer to pair program with her even if she doesn’t ask. Similarly, always accept help when it’s offered and ask for it when you’re stuck. It’s unprofessional to waste paid time staring at a screen when help is available.
Rule #9: Deal with interruptions efficiently and gracefully. You’ll inevitably be interrupted while coding. Here are some strategies to quickly refocus on your work after an interruption:
- Pair program. When you get interrupted, your partner can keep track of your place and thought process.
- Use a workflow that holds your place for you. For example, in test-driven development (more in Quality #4), you alternate writing short tests and short pieces of code. Because these steps are in such a strict order, you can quickly find your place when you return.
Quality #3: Be Honest About Deadlines
The third professional quality is honesty, especially in the face of 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 guaranteed commitment. Estimates aren’t promises, so missing them isn’t unprofessional, but professionals do make their estimates as accurate as possible.
To that end, estimates 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.
When giving estimations, you should mention all three numbers.
Quality #4: Communicate via Testing
The fourth professional quality is 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. The best way to do that is via acceptance testing.
Acceptance tests are automatic tests that determine if the system behaves the way the business wants it to—in other words, these tests specify what the system is supposed to do. Therefore, acceptance tests are the most unambiguous way to communicate about system requirements—there’s no possibility of misunderstandings or inaccurate assumptions.
- For example, if a client requires that an operation completes in under two seconds so a user doesn’t experience a delay, the test checks if the operation completes fast enough.
Acceptance tests are co-written by clients and testers or QA (Quality Assurance). The client will usually come up with the happy-path test and QA will write the unhappy-path tests that cover unusual scenarios. Then, it’s the developers’ job to add the tests to the system and build something that passes them.
Quality #5: Manage Your Time Well
The fifth quality of professionals is that 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 by:
1. Avoiding time-wasting meetings. Only go to meetings if you’ll gain information that’s important to your current project, your presence will help someone, the meeting is about something interesting and you have time, and/or the meeting has an agenda, schedule, and goal. If the meeting stops meeting these criteria partway through, ask to get back on topic or leave.
2. Running meetings efficiently. Many of the meetings you attend will be structured based on the Agile canon. (Shortform note: Agile is a collection of software development practices.) Here’s how to run the three types efficiently:
- Stand-up meetings. All participants must stand during the meeting, and everyone gets only 20 seconds to respond to each of the following questions:
- What did you work on yesterday?
- What are you going to work on today?
- What’s preventing you from doing what you’re going to do today?
- Iteration planning meetings. The goal of these meetings is to choose which backlog tasks to include as part of the following iteration. The discussion of each task should only take five to 10 minutes because estimates, business values, and acceptance tests for tasks should be established before the meeting.
- Iteration review. Hold these meetings at the end of every iteration. The goal is to talk about what went right and wrong (maximum of 20 minutes) and to demo the results of the iteration to stakeholders (maximum of 25 minutes).
3. Keeping a handle on arguments. If an argument breaks out during a meeting and it lasts more than five to 30 minutes, further discussion isn’t productive. You can settle the argument either by gathering more data (likely no one can win because no one has convincing evidence) or asking meeting participants to voice.
Technique #2: Use the Pomodoro technique. Pomodoro is a way of reserving chunks of time for uninterrupted (and therefore productive) work. It works like this:
- Start a timer for 25 minutes. Focus on your work for 25 minutes and don’t let anyone interrupt you. When the timer goes off, stop working.
- Address any interruptions you ignored during your 25 minutes.
- Take a five-minute break.
- Do another 25 minutes of work.
- After four 25-minute sets, take a half-hour break.
Technique #3: Avoid priority inversion. Priority inversion is when you avoid unpleasant work (work that’s dull, frightening, or uncomfortable) by doing a lower-priority task instead (and often invent some justification). Do your tasks in the real priority order.
Technique #4: Avoid and abandon dead ends and messes. Abandon a course of action as soon as you realize it’s going nowhere and try something else. Don’t get mired in a mess before you officially hit the dead end—turn back as soon as possible.
Quality #6: Collaborate
The final quality of professionals is the ability to work with others. We’ll cover two elements of collaboration:
Element #1: Teamwork
Professionalism involves doing whatever produces the best possible work, and the majority of the time, the best work is achieved via collaboration. The best way to collaborate is to put together a permanent team that works on multiple projects together (versus making a new team for every new project) because:
- It takes time for a team to become effective. It can take six months to a year for a group of people to gel (learn how to work together by leveraging strengths and weaknesses, supporting each other, and so on).
- Teams that work on multiple projects can better allocate strengths and weaknesses. (Shortform example: People who are good at debugging can work on the debugging aspects of all the projects.)
- The team can quickly adjust priorities. If one of the team’s projects goes into crisis, the team can pause on their other projects and focus on that one.
Once a team is assembled, here are some techniques for effective collaboration:
1. Share code. Anyone should be able to make improvements to any part of the code. That way, people can work with each other and learn from each other.
2. Pair program. Not only is pair programming efficient, but it also allows people to share knowledge about both the system and the business, and familiarity with other people’s work allows team members to take over for each other in emergencies. Additionally, pair programming is the most efficient way to review code.
3. Work physically close to each other. Face each other when you’re sitting around a table, and be close enough to talk and read body language.
Element #2: Mentoring
In addition to teamwork, collaborate by mentoring. It’s the professional and ethical duty of experienced programmers to mentor newbies, and it’s newbies’ duty to ask for mentorship. This is because inexperienced coders can cost a company a lot of money and do a lot of damage.
- For example, software controls some high-stakes systems such as banking systems.
Mentoring teaches technical skills and professionalism, and instills craftsmanship—the mindset of attitudes, techniques, values, and disciplines required for coding. Mentoring is the only way to learn many of these skills—school and courses can teach theory but not practice.
Martin’s ideal mentoring system includes the following roles and responsibilities.
- Masters have over 10 years of experience with various systems and languages, have led at least one important project, and are skilled coders, architects, and designers. Masters mentor journeypeople.
- Journeymen and women have around five years of experience with one system and language. They mentor less experienced people.
- Apprentices have less than a year of experience. They don’t have their own tasks—they help journeymen and women and regularly participate in pair programming.
The level of mentorship required depends on experience. The less experienced an apprentice or journeywoman, the more supervision is required. Apprentices should have no autonomy, and experienced journeywomen should be peer-reviewed.
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Robert C. Martin's "The Clean Coder" at Shortform .
Here's what you'll find in our full The Clean Coder summary :
- Why many don't consider developers to be "professionals"
- Why continued professional development is so important
- How you can develop the six qualities and skills of a professional coder
