PDF Summary:The Clean Coder, by Robert C. Martin

Have you ever been frustrated that some people don’t consider developers “professionals?” These people trust lawyers to meet deadlines, or doctors to keep up with the cutting edge of their fields, but when it comes to programmers, they think they have to babysit and micromanage them.

Programmers can be just as professional as any other worker, and in The Clean Coder, professional developer Robert C. Martin will teach you how. You’ll learn how to commit to professional development, discipline, honesty, and communication, and you’ll learn to become an efficient team member and mentor.

(continued)...

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.

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.

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:

1. 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.
2. You can’t write any more of the test beyond the first failure. (Not compiling counts as a failure.)
3. 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).

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.