#6 Practicing - Tips from The Clean Coder
Tags: tips, habits, beginners, productivity
Published: 2020-08-17 00:24:09

---
title: #6 Practicing - Tips from The Clean Coder
published: true
description: Some tips from the book The Clean Coder, by Uncle Bob.
tags: #tips #habits #beginners #productivity
//cover_image: https://direct_url_to_image.jpg
---

#####*This is the sixth article from the series "Tips from The Clean Coder". Here we gathered and summarized the main tips from the sixth chapter.*

All professionals practice their art by engaging in skill-sharpening exercises. Musicians rehearse scales. Football players run through tires. Doctors practice sutures and surgical techniques. Lawyers practice arguments. Soldiers rehearse missions. When performance matters, professionals practice.

![practice]
(https://media.giphy.com/media/8AfVHQbGG8dxGCC7ES/giphy.gif)

### Some background on practicing

Practicing is not a new concept in software development, but we didn't recognize it as a practice until just after the turn of the millennium. Perhaps the first formal instance of a practice program is the "hello world".

We use it as a way to prove a new environment or a new language. Writing and executing that program is proof that we can write and execute *any* program.

![old]
(https://media.giphy.com/media/VDB85YZsrqMXx3c7DE/giphy.gif)

Things have changed since the early days of programming. Some things have changed a lot. Other things haven't changed much at all.

We've got better tools to write those classic statements (*if* statements, *while* loops and *assignments*) with. But the nature of the statements hasn't changed in all that time. Code in 2010 would be recognizable to a programmer from the 1960s. The clay that we manipulate has not changed much in those four decades.

#### Turnaround time

But the way we work has changed dramatically. In the '60s I could wait a day or two to see the results of a compile. In the late '70s, a 50,000-line program might take 45 minutes to compile. Even in the '90s, long build times were the norm.

Programmers today don't wait for compiles. They have such immense power under theirs fingers that they can spin around the red-green-refactor loop in seconds.
![fast]
(https://media.giphy.com/media/13UZisxBxkjPwI/giphy.gif)

It's not always wise to go that fast. Often is better to slow down and just think. But there are other times when spinning around that loop as fast as possible is *highly* productive.

Doing anything quickly requires practice. Spinning around the code/test loop quickly requires you to make very quick decisions. Making decisions quickly means being able to recognize a vast number of situations and problems and simply know what to do to address them.

Consider two martial artists in combat. Each must recognize what the other is attempting and respond appropriately within milliseconds. In combat, you don't have the luxury of freezing time, studying the positions, and deliberating on the appropriate response. You simply have to *react*. Indeed, it's your *body* that reacts while your mind is working on a higher-level strategy.

![key]
(https://media.giphy.com/media/26BGIqWh2R1fi6JDa/giphy.gif)

When you're spinning around the code/test loop several times per minute, it is your *body* that knows what keys to hit. A primal part of your mind recognizes the situation and reacts within milliseconds with the appropriate solution while your mind is free to focus on the higher-level program.

In both the martial arts case and the programming case, speed depends on *practice*. And in both cases the practice is similar. We choose a repertoire of problem/solution pairs and execute them over and over again until we know them cold.

### Kata

In martial arts, a *kata* is a precise set of choreographed movements that simulates one side of a combat. The goal, which is asymptotically approached, is perfection.

The purpose of learning a kata is not to perform it on stage but to train your mind and body how to react in a particular combat situation, doing the perfected movements automatic and instinctive.

![kata]
(https://media.giphy.com/media/xT0BKGdOtPSQe5TL5S/giphy.gif)

A programming kata is a precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. You aren't actually solving the problem because you already know the solution. Rather, you're practicing the movements and decisions involved in solving the problem.

Practicing a suite of katas is a food way to learn hotkeys and navigation idioms. It is also a good way to learn disciplines such as TDD and CI. But most importantly, it is a good way to drive common problem/solution pairs into your subconscious, so that you simply know how to solve them when facing them in real programming.

### Wasa

When I studied jujitsu, much of our time in the dojo was spent in pairs practicing our *wasa*. Wasa is very much like a two-man kata. The routines are precisely memorized and played back. One partner plays the role of the aggressor, and the other partner is the defender. The motions are repeated over and over again as the practitioners swap roles.

![was]
(https://media.giphy.com/media/B3u6LIYUA4A1i/giphy.gif)

Programmers can practice in a similar fashion using a game known as *ping-pong*. Both partners choose a kata, or a simple problem. One programmer writes a unit test, and then the other must make it pass. Then they reverse roles.

### Randori

*Randori* is a free-form of combat. In our jujitsu dojo, we would set up a variety of combat scenarios and then enact them. But simulated combat does not map well to programming. however, there is a game that is played in many coding dojo called randori. It's very much like two-man wasa, but it's played with many people and the rules have a twist.

With the screen projected on the wall, one person writes a test and then sits down. The next person makes the test pass and then writes the next test and so on.

![randori]
(https://media.giphy.com/media/l2Je5K36gfVjK1MBi/giphy.gif)

You can gain an immense insight into the way other people solve problems. These insights can only serve to broaden your own approach and improve your skill.

### Broadening your experience

Professional programmers ofter suffer from a lack of diversity in the kind of problems they solve. Employers often enforce a single language, platform, and domain. Without a broadening influence, this can lead you to a very unhealthy narrowing of your resume and your mindset.

#### Open-source

One way to stay ahead of the curse is to take on some pro-bono work by contributing to an open-source project. There is no probably better way to improve your repertoire of skills than work on something that someone else cares about.

![open-source]
(https://media.giphy.com/media/cnhpl4IeYgU7MCBdV2/giphy.gif)

#### Practice ethics

Professional programmers practice on their own time. Employers don't have to pay you for your practice time. Since your practice time is your own time, you don't have to use the same languages and platforms that you use at work.

### Conclusion

In one way or another, *all* professionals practice. They do this because they care about doing the best job they possibly can. The practice in their own time because they realize it is their responsibility to keep their skill sharp. Practicing is what you do when you aren't getting paid. You do it so that you will be *paid*, and paid *well*.

![practice]
(https://media.giphy.com/media/8vkEKXvnXkyCZx8w6b/giphy.gif)


##### Next article: [#7 Acceptance Testing](https://dev.to/yurishenrique/7-acceptance-testing-tips-from-the-clean-coder-2j8g)

##### Previous article: [#5 Test-Driven Development](https://dev.to/yurishenrique/5-test-driven-development-tips-from-the-clean-coder-35mn)