You already know what a kata is: a small coding exercise that you repeat to practice technique, not to ship. The problem is that many kata sessions become just “solving the exercise again” — and then they teach very little. The difference between a kata that delivers value and one that merely passes the time is almost never the exercise. It’s how you run the session.
Timebox it and delete everything at the end
Set the time before you start: 45 minutes, an hour, whatever works. When the timer goes off, you’re done — even if the code isn’t “finished.” The goal isn’t to complete the exercise; it’s to practice.
And delete it at the end. Delete the code and close the branch without committing. It may seem wasteful, but that’s the whole point: when you know you’re going to throw it away, you stop getting attached to the solution and start paying attention to the process.
Vary the constraints — that’s where the learning happens
Repeating the same kata in the same way teaches you to memorize the answer. Repeating it with a new constraint forces you to think again. Here are some that work well:
- TDD only, no exceptions: no production code without a failing test first.
- No
if: no conditionals — it pushes you toward polymorphism, lookup tables, and the null object pattern. - Functions of no more than 3 lines: forces you to extract and name each step.
- No mouse / keyboard only: trains navigation and IDE-assisted refactoring.
- Complete silence in pairs: only the code and tests communicate.
Use one constraint per session. Two at the same time turn it into a puzzle, not practice.
Ping-pong: pairing that forces focus
The ping-pong format is the best way to do a kata in pairs. Person A writes a failing test. Person B makes the test pass and writes the next failing test. Person A makes that one pass, and so on.
The result is that no one sits on the sidelines. Whoever isn’t typing is thinking about the next test. And because the test comes from the person who won’t implement it, you stop writing tests tailored to your own mental solution.
Group dojo: rotation and an audience that participates
In a coding dojo, using the Randori format, a pair works in front of everyone with the screen projected. Every 5–7 minutes, they rotate: the person at the keyboard returns to the audience, the person who was co-piloting takes over, and someone from the audience joins.
Two rules that keep a dojo on track:
- The audience only comments when the tests are green. Debating design with a failing test on the screen turns into chaos.
- Whoever joins takes the code as it is, without complaining. The goal is to continue the group’s reasoning, not impose your own.
A facilitator takes care of the timer and the rules without touching the code.
Choose the right kata for the goal
The exercise isn’t neutral — each one trains something different. Choose based on what you want to practice today:
- FizzBuzz / Roman Numerals: TDD rhythm and small steps. Great for warming up or for people who are just starting out.
- Bowling / Gilded Rose: refactoring messy logic and getting coverage in place before making changes.
- Mars Rover / Bank Account: design, separation of responsibilities, and modeling.
Running Gilded Rose to practice “small steps” or FizzBuzz to practice architecture wastes the session. Match the kata to your intention.
Save the last 10 minutes for reflection
Without a retrospective, a kata becomes exercise without purpose. Stop before the end and ask, as a group or by yourself: what did today’s constraint force us to do differently? Where did we get stuck? Which step would we repeat, and which would we cut?
This conversation is what turns practice into transferable learning — what you take with you to real code tomorrow.
A good kata isn’t the one you solve fastest. It’s the one that makes you uncomfortable to just the right degree, with a clear constraint, a format that keeps everyone thinking, and five minutes at the end to understand what changed in your head. Choose one constraint for your next session and delete the code at the end. The learning stays.
