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 are the characteristics of a good programmer? What traits and qualities distinguish a “good programmer” from an “average programmer”?
In The Clean Coder, Robert C. Martin, describes six qualities of a great programmer: 1) commitment to professional development, 2) discipline, 3) honesty, 4) professional communication, 5) time management, and 6) ability to work with others. Further, he shares the lessons learned the hard way, in the hopes that he can help the reader cultivate these traits and avoid making some of his mistakes.
In this article, you’ll learn about Martin’s six characteristics of a good programmer and how to develop them.
What Makes a Great Programmer?
Many people (including developers) don’t consider developers professionals, and this is partly because developers don’t act like professionals. Robert 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.
Here are the six skills and characteristics of a good programmer.
- Commitment to professional development
- Discipline
- Honesty (around estimates and deadlines)
- Communication (via testing)
- Time management
- Collaboration
1. Commitment to 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).
2. 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. 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.
3. Honesty
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.
Defending Your Estimations
There’s always the possibility that people won’t like your estimates and will want something done faster. If this happens, you have three options, not all of which are professional:
1. Saying “no.” Saying no has a bad rap, but it’s the most professional thing to do in many situations. If it’s impossible to get something done properly (adhering to discipline) by a certain deadline, and you say anything other than no, you’re essentially lying.
2. Saying “try.” Never agree to try to do something in a time period shorter than your estimation. People often interpret “try” to mean “yes” or “maybe,” and both are lies because if you’re a professional, you’ve already been giving the project your full effort. There’s nothing more you can do that would make things go faster.
3. Saying “yes.” Only say yes when you know you can meet a deadline because a yes is a commitment. If it’s impossible to say yes to something in its current form, ask to change the parameters of the task so that you can say yes. For example, you might ask to reduce the scope of the project so that there’s less to do and you can finish in a shorter amount of time.
4. Communication
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.
First, we’ll 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.
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.
The Pyramid of Tests
There is a pyramid of testing that ensures a system works and that it behaves the way a business wants it to. We’ll start at the bottom and move up:
Level #1: Unit tests test “units”—small sections of code. They cover as much of the code as possible (at least 90%) and their purpose is to specify the system. They run continuously and they’re written before the code by developers using test-driven development (TDD).
There are three rules to TDD:
- You can’t write code until you write a unit test that fails. (The test will fail because it needs code to evaluate, and the code isn’t written yet.)
- For example, if you plan to write a function, you’ll have to mention its name in the test. The test will fail because the function doesn’t exist yet.
- You can’t write any more of the test beyond the first failure. (Not compiling counts as a failure.)
- You can’t write more code than you need to pass the test.
TDD comes with several advantages:
- The cycle time is fast. Since you write and test only a little bit of code at a time, you regularly execute the code.
- You know your code works and can update with confidence. In TDD, you test every single time you make a change, so you have confirmation that what you’ve written will work.
- There are fewer bugs. For example, Martin uses TDD on a project called FitNesse, and FitNesse only had 17 bugs after he added 20,000 lines of code.
- They facilitate good (decoupled) design. Decoupled code is easier to work with because when a test identifies a problem, you can quickly find it—there aren’t layers of code the wade through.
- Tests double as documentation. The TDD unit tests act as instructions for how to use the program because they cover every piece of the system.
Level #2: Component tests (which include acceptance tests) test individual components and business rules. They cover 50% of the system and run continuously, just like unit tests.
Level #3: Integration tests assess how well different components communicate (only relevant in multi-component systems). They cover 20% of the system, execute periodically, rather than continuously (they’re time-consuming), and are written by the system’s lead designer or system architect.
Level #4: System tests are the highest form of integration tests and they evaluate the whole system. They cover 10% of the system, execute infrequently (they’re time-consuming), and are written by the technical leads or system architects.
Level #5: Manual exploratory tests are tests in which humans use the system to confirm how it works and report bugs. They cover 5% of the system, are executed infrequently (they’re expensive), and aren’t written (people explore the system however they like).
5. Time Management
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:
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.
6. Ability to Work With Others
The final quality of professionals is the ability to work with others. In The Clean Coder, Martin covers two elements of collaboration:
- Collaborative
- Mentoring
Collaborative Coding
There are three 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.
Mentoring
Mentoring teaches technical skills and professionalism and instills craftsmanship—the mindset of attitudes, techniques, values, and disciplines required for coding.
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.
———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
