A code kata is a formulaic or choreographed way to practice programming skills. Many katas can be done in different ways to achieve different learning goals. Others are designed to help us internalize a sequence of steps to address common programming problems we encounter in our work.
In 2012, writing on an blog I used to maintain, I attempted to explain why we practice code katas. Based on observations of coding dojos and similar meetups in the years since then, it seems to me people still don’t understand the purpose of a code kata, or how to use katas to build skills.
When I searched for an explanation of how katas are used in martial arts, I discovered a very good explanation by martial artist Martin Jutras, on the Karate Lifestyle site. One thing that makes his explanation particularly relevant is that he addresses common misconceptions about katas. I’d like to quote from that site now, and correlate Jutras’ observations about martial artists with my observations about programmers, in the hope of clarifying the role of code katas in our professional development.
What is Kata?
Under the heading, What is Kata? Jutras writes:
“Kata, a Japanese word meaning ‘form’, is a system of individual training incorporating highly practical combat techniques and notions that have been cultivated and polished for centuries.”
Paraphrasing in the context of programming, we can say:
“Code Kata, a term coined by Pragmatic Dave Thomas, is a system of coding practice incorporating techniques and notions that have been cultivated and polished for decades.”
I’m sure you can see where the metaphor comes from. Of course, metaphors only go so far. In this case, the metaphor may go farther than you realize.
Jutras goes on to say:
“It might sound obvious, but kata requires lots of training and repetition to master. In fact, it takes years of practice to execute and understand a kata fully.”
Countless programmers have experienced at least one code kata, facilitated and executed in some manner, however rigorously (or not). But those who have practiced katas mindfully all report they have learned a good deal about effective software development in this way. I’m thinking of people like Dave Thomas, Michael “Geepaw” Hill, Robert “Uncle Bob” Martin, George Dinwiddie, Jeff “Cheezy” Morgan, Llewellyn Falco, Arlo Belshee, Ron Jeffries, Chet Hendrickson, Emily Bache…well, you get the idea. By repeating katas hundreds, even thousands of times, these individuals and others have discovered useful nuances about effective software development that probably would not be intuitively obvious in the absence of such practice.
Misconceptions about Kata
Jutras enumerates several common misconceptions about kata in martial arts, every one of which has an analogue in the software development field.
Misconception #1: “Kata is an imaginary fight against a group of people. […] Ancient Chinese and Okinawan masters knew that even a simple confrontation can be enormously chaotic and unpredictable so there is no way they would codify a fight against a whole group of people.”
Exactly the same misconception is common in the software field. Many programmers assume the purpose of a code kata is to deliver the finished product that is described in the instructions for the kata. They complain that code katas are too simplistic to provide useful practice for real-world problems. After all, no real customer will ever ask you to write FizzBuzz for them.
The truth is the purpose of a code kata is to practice and internalize programming technique. The finished product is irrelevant. The problems are designed to keep real-world distractions out of the way so that we can focus on practicing the techniques.
Misconception #2: “Katas don’t have any real-world application. […] It is essential to understand that all movements within the katas are designed for to be used in real fights or combat. Please allow me to formulate this again in different words. The principal purpose of kata movements and techniques is to disable an attacker in an actual physical conflict.”
Yes, it’s true that real-world problems are more complicated than any code kata. It’s also true that real-world problems naturally break down into a series of simple problems. Many of those simple problems are similar to code kata exercises, and not by accident.
Martial arts kata comprise short sequences of moves that counter specific, single attacks. Similarly, code katas (some of them, at least) are designed to reflect programming problems that have particular shapes.
When you decompose a “real world” problem into its constituent simple problems, you find some of them have the shape of a single input that is processed to produce zero to many outputs, like the Prime Factors kata. Some have the shape of a list of elements that is transformed by applying an algorithm or function to each element in the list, like the FizzBuzz kata. Some have the shape of taking an initial value and deriving the next value in a series, and then deriving the third value based on the previous ones via some formula, like the Fibonacci Series kata, and the slightly more-complicated variant of that shape represented by the Bowling kata. Some have the shape of learning which sequences of elements tend to occur together in a given text, and then using that information to generate new sequences of text that make some sort of sense, like the Trigrams kata. The list goes on. Each of these has direct application in real-world software development.
We must put together the right skills to deal with real-world programming challenges, just as the martial artist must put together the right skills to deal with a self-defense situation. They don’t simply repeat the steps of a kata when they are assaulted on the street, and we don’t simply repeat the steps of a code kata when we face a real-world problem. In order to do so, martial artists and programmers (and countless others who work in other disciplines) must deeply internalize the individual skills involved to solve each shape of small problem. It’s very difficult to achieve that if you only ever apply your skills in real-world situations, with all the complexity, uncertainty and pressure they bring.
Misconception #3: “Many people believe that kata are filled with ‘hidden’ deadly techniques and moves waiting to be unlocked.[…] Why would you want to hide ‘deadly’ techniques into an obviously martial looking form? […] I think the real reason why people say that the actual techniques of kata are hidden is simply that they don’t know the real applications of the forms. Most people are clueless regarding the practical use of kata.”
I’ve heard programmers express a similar misconception regarding code katas. And it is true in our field, as well, that many programmers don’t understand the real applications of the techniques we practice in code katas.
But in our case, I don’t think the misconception arises because of assumptions about mysterious, ancient, foreign masters trying to hide their secrets from the authorities or rivals. Instead, I think it comes about because experienced practitioners tend to say that practicing code katas numerous times will cause new learnings about programming to become visible to you.
This may sound a bit mystical to a programmer who has tried a code kata and found it to be so simple that he doesn’t understand what more there could possibly be to learn. Therefore, these “master programmers” must have secrets, after all. But they don’t. It’s just practice. The thing is: The more practice, the better.
More about Kata
Moving on from misconceptions, Jutras goes on to explain;
“…kata should not be seen ‘as a whole’ or as a continuous combat scenario against multiple opponents. In reality, each kata is composed of dozens of specific ‘micro-sequences’. Try to break down and see the techniques of kata on a smaller scale. What do I mean by that? Well, one technique should be dissected into pretty much one attack from the opponent, then followed by your defense and counter-attack(s). That’s it.”
When the facilitator asks participants in a code dojo to follow the steps of classic-style test-driven development to the nth degree, many novice practitioners become impatient. “This problem is so obvious, I could just code it all right now and be done with it!”
But to obtain the maximum value from practicing code kata, it’s helpful to pay close attention to the “micro-sequences” and learn how they affect the emerging design of the code.
Consider the Prime Factors kata. Ultimately, we want to build a routine that can extract the prime factors from any non-zero, positive integer. But we don’t approach the problem in a single go. The first step in the kata is to extract the prime factors of the number 1. That’s all. Just that. Nothing more.
So, we write an example – also known as a “unit test” – that passes the number 1 into the (not-yet-written) routine, and expects to see an empty list come back; the number 1 has no prime factors. That’s equivalent to “one attack from the opponent.”
Notice how small that unit test is. Most programmers don’t properly grasp how small these steps need to be. And the word “unit” doesn’t have a consistent definition. A “unit” of code can be anything, really. You can’t be wrong about it.
That’s why Geepaw Hill coined the term microtest. He wanted to clarify what we mean when we say “write a small example.” Here’s GeePaw on YouTube explaining the concept: Microtests: A Geepaw Hill Quickie.
Then we write just enough code to make the unit test pass. That’s all. No more code than that. It means, literally, we write a routine that does nothing except return an empty list. It contains no logic.
Obviously, that’s not a solution to the prime factors problem. That’s okay. This is just one move in the kata. The failing example is the opponent’s attack; the extremely minimal code to make the example pass is the single response to the attack. Your opponent throws a punch (the failing example). You block it (the minimal code to make the example pass).
The next move in the kata is to extract the prime factors of the number 2. And so on. Just one small step at a time.
Why is practice important?
Jutras lists four key benefits of practicing kata in martial arts. The same benefits accrue to practitioners of code katas.
Benefit #1: Develops proper body mechanics.
The steps of the TDD cycle, red-green-refactor, are the programming equivalent of body mechanics in martial arts. People who have read about, heard about, or carelessly attempted to do TDD usually think they understand it very well. After all, the “rules” are pretty simple. But this is a discipline that is cultivated through mindful repetition. It’s very easy to keep on writing production code instead of stopping when you’ve made the latest new microtest pass, and even easier than that to forget to refactor altogether. By practicing kata the right way, we cultivate the self-discipline to use the TDD method effectively.
Benefit #2: Builds muscle memory.
As you proceed, you reach points in the emerging solution that call for some sort of design decision; a small one, of course. Not architectural decisions. Do you introduce another else block, or is it time for a switch statement? That sort of thing.
Many programmers who are new to this approach become confused about what step to take next. That’s why the kata are choreographed; we practice the steps in the defined order, for a reason.
After practicing kata mindfully thousands of times, Uncle Bob Martin came to the realization that it makes a difference which small design decisions you make as you proceed with small steps during the kata. He calls this the Transformation Priority Premise, documented on his blog. The point of following these guidelines is to make your life as a programmer easier by helping you avoid going down dead ends in the emerging solution design, and to help you end up with a clean solution.
Through repeated, mindful practice, we develop the instinct or habit to choose the “right” design decisions along the way, so that a robust implementation emerges with a minimum of stress on us.
Benefit #3: Develops mindfulness.
Repeated practice helps us remember to follow the steps; that much is probably obvious. But it also helps us cultivate mindfulness about the shape of the problem we’re solving, when we apply these techniques in the scope of a larger software development problem. Large problems decompose into small ones, and each small problem has a shape. Many of these resemble the shapes of code kata that we have practiced over the years.
You apply the techniques whenever you encounter a problem of similar shape in your real work. Having cultivated mindfulness about this, you needn’t spend as much time in analysis, as you can simply recognize the shapes of problems, and subsets of problems, as if you were meeting old friends.
Benefit #4: Develops proper breathing.
The connection of proper breathing with programming may be less obvious than the other three points. Jutras explains:
“One of the most critical aspects of Kata is proper breathing. A kata without proper breathing won’t have power, snap, and explosiveness – it will feel weak.”
“When the mind stops overthinking, when the thoughts are ‘getting out of the way’, proper breathing naturally sinks in. The breath becomes slower, more powerful, and the body adjusts by automatically exhaling at the end of a technique, resulting in an important increase in strength, energy, and stability.”
Those of you who practice martial arts in addition to programming already know that when you perform a kata, you do the moves on a steady cadence. You don’t do the first move, then wait 5 seconds, then do three moves in a row rapidly, then wait 2 seconds, then a move, then wait 4 seconds, etc. It’s tick-tock-tick-tock.
Similarly, when test-driving a software solution in a pair or in a mob, you don’t write a failing microtest, then go get coffee, then make the microtest pass, then argue about curly brace placement for 20 minutes, then forget which microtest you intended to write next, etc. You get into a rhythm, whether alone, with a pairing partner, or in a mob programming setup.
The equivalent of breathing in programming is steady pace. In martial arts, as well as in endurance sports like basketball, cross-country skiing, long-distance running, swimming, and others, the way you keep yourself going is by controlling your breathing. The rhythm – the breathing – of a software development team enables the team to achieve the goal of sustainable pace. You aren’t exhausted at the end of the day, and the team doesn’t collapse on the floor after each software release.
In fact, rhythm is important in every aspect of life. Here’s a video I like to watch periodically to remind myself of the importance of rhythm: There Is No Movement Without Rhythm.
Inexperienced programmers often don’t relate to the way this can feel. I remember getting into a good flow with various pair programming partners and in mob programming sessions. The smoothest and fastest that I remember was when I was pairing with one of the programmers mentioned above, Jeff “Cheezy” Morgan. We were doing red-green-refactor cycles and committing to version control at 90-second intervals. It was energizing, not tiring.
Many programmers think they’re going “fast” if they commit to version control once a day. This is the kind of difference frequent, mindful practice can make in your work. You can’t work that way if you have to pause frequently to try and remember what you’re supposed to do next. It has to be second nature.
There’s a US Army slogan that goes something like this: Slow is smooth. Smooth is fast.
If you wait 20 hours for your primary stakeholder to decide what they want you to write, then break your balls for six hours coding without tests, then fight through frustration and fatigue to fix the code, and then wait 36 hours before a “testing team” can look at your code, it’s as if you took 40 punches before you bothered to execute your first block. That’s not a sustainable pace of work. That’s burnout in progress. Wouldn’t it be better if you felt like dancing at the end of the work day, like the people in the video?