You close twenty tickets a week and still feel like your technique has stalled? It’s not your fault: delivering software isn’t the same as practicing. A code kata is how you separate the two.

What exactly is a code kata
The name comes from karate: a kata is a sequence of movements you repeat until they become automatic. The idea is the same in code. You take a small, familiar problem and solve it again and again, focusing on HOW you solve it—not on finishing.
Here’s the part that confuses everyone: the goal isn’t the answer. You already know the answer. The goal is the approach—how you name things, how you break down the problem, how you write the test first.
Why deliberate practice beats grinding through tickets
A ticket is work under pressure: deadlines, legacy code, people waiting. You solve it however you can and move on. Do you learn something? Sometimes. Consistently? Almost never.
Deliberate practice is the opposite: a controlled environment, an easy problem, and zero delivery pressure. That frees your mind to pay attention to technique. It’s the difference between driving to work every day and practicing parallel parking in an empty lot. One gets you places; the other makes you a better driver.
How to run your first kata
The recipe is intentionally simple:
- Choose a small problem. FizzBuzz, Roman Numerals, Bowling. Something you can solve in less than an hour.
- Set a timebox. 30 minutes. When time is up, stop—even if you haven’t finished.
- Repeat with a constraint. This is where the magic happens. Did it again? Now do it once more with a rule: no
ifstatements, immutable code only, strict TDD, or no mouse.
The constraint pulls you out of autopilot. Without if statements, you discover polymorphism the hard way. Without a mouse, you finally learn your editor’s keyboard shortcuts. Each repetition gives you a new angle on the same problem.
And delete the code at the end. Seriously. The artifact doesn’t matter—what stays is in your head and in your fingers.
Ping-pong: kata in pairs
Kata is even better in pairs, and the classic format is ping-pong:
- Person A writes a failing test.
- Person B makes the test pass and writes the next failing test.
- Person A makes that one pass, then writes the next. And so on.
One person writes the test, the other implements it, and they alternate. You’re forced to talk about design, justify every step, and experience TDD for real instead of just reading about it. It’s uncomfortable at first and addictive later.
Where to find katas to get started
You don’t need to invent a problem. There are already catalogs available:
- Codewars — katas organized by level, great for gradually increasing the difficulty.
- Exercism — exercises with mentoring and human feedback, across dozens of languages.
- codekata.com and Coding Dojo (codingdojo.org) — classic katas, with context and variations.
- cyber-dojo.org — designed for group kata sessions, running in the browser.
Start with FizzBuzz today. Ridiculously easy? That’s the point—the simplicity is what lets you focus on technique.
Grinding through tickets pays the bills. Kata is what makes you better. Set aside 30 minutes, choose a silly problem, and run your first one today.


