Coding dojos for mobile teams: how a live kata session works

The first ten minutes of a coding dojo always feel slow. Two people sit at one laptop that is mirrored onto a wall, a timer is running, and the only thing on screen is a test that fails. Everyone else in the room is watching, a little unsure whether they are allowed to talk yet. By the end of the evening the code will probably be deleted, and that is the point.

A dojo is a practice session for programmers. Nobody ships anything. A small group solves a small, well-known problem in the open, with tests first and in small steps, so that the way people work becomes visible and can be discussed. For mobile teams, who spend most days fighting build times, store reviews and device quirks, it is one of the few places where you get to practice the craft itself.

Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.

Where the format comes from

The word "kata" was borrowed for programming by Dave Thomas, co-author of The Pragmatic Programmer, for short exercises meant to be repeated many times, the way a martial arts form is. The dojo idea followed in Paris in the mid 2000s, when Laurent Bossavit argued for a regular place to practice and Emmanuel Gaillot helped start one. Groups in other cities picked up the format, and the community site at codingdojo.org still collects the session formats and katas people use.

The two classic formats

Most dojos use one of two formats, sometimes both in one evening.

In a prepared kata, the presenter starts from an empty project and solves the problem live, test by test, explaining each step. It is closer to a performance than a lecture: the value is in seeing the small decisions, such as which test to write next and when to stop and refactor.

In a randori, everyone takes a turn. Two people go to the keyboard, one as driver and one as copilot, and they start from scratch. The room is expected to follow and help, with one important rule from the randori description on codingdojo.org: suggestions come mainly when the tests are green. While a test is red, the pair at the keyboard can ask to be left alone.

Pair rotation and TDD in the room

The rotation is what makes a randori work. There are a few common ways to run it:

• Timebox: a timer of five to seven minutes. When it rings, the driver returns to the audience, the copilot takes the keyboard, and someone new from the room becomes copilot.
• Ping-pong: one person writes a failing test, the other makes it pass and writes the next failing test, then they swap.
• Per test: the pair changes after each new passing test, which keeps steps small without a clock.

The rhythm inside each turn is the usual test-driven loop: write a failing test, make it pass with the simplest code that works, then clean up while everything is green. In a room, this has a social side effect. A red bar is a shared problem, a green bar is a moment to talk, and a long silence at the keyboard is a sign the step was too big.

For a mobile team, the test loop must be fast. A JVM unit test in a plain Kotlin module runs in a couple of seconds through Gradle; an instrumented test that needs an emulator does not, and a five-minute turn cannot afford a three-minute boot. On the iOS side, a small Swift package with swift test keeps the simulator out of it entirely.

import kotlin.test.Test
import kotlin.test.assertEquals

class RomanNumeralsTest {
    @Test
    fun `one is I`() = assertEquals("I", roman(1))

    @Test
    fun `four is IV`() = assertEquals("IV", roman(4))
}

That is the whole starting point. A function called roman does not exist yet, and the first driver's job is to make the first test compile and pass.

Running one for a mobile team

A dojo needs very little: a room, a screen everyone can read, a laptop and a problem. The preparation is mostly about removing friction.

1. Book 90 minutes to two hours. Shorter sessions end just as people warm up. Longer ones lose the room.
2. Choose one kata and one language. Kotlin or Swift, decided in advance. Mixed iOS and Android teams can alternate from one session to the next.
3. Prepare an empty project that already runs a test. Check it the day before on the machine you will use. Gradle downloading dependencies over the office guest network is not a kata.
4. Fix the hardware. One laptop, one external keyboard with a common layout, a font size readable from the back row, and notifications switched off.
5. Explain the rules in two minutes. The format, the rotation, when the audience may speak, and that the code will be thrown away.
6. Keep a facilitator who does not type. That person watches the clock, protects the pair during a red bar, and stops a debate that has run for three turns.
7. End with a short retrospective. What did we learn, what would we try differently, which kata next time. Fifteen minutes is enough.

Newcomers fit in well, which makes a dojo a good next step after a beginners' plan such as Android for beginners in four weekends. Pair the first-timer as copilot with someone experienced, never as driver on the first turn.

Katas that suit app developers

The classics are classics for a reason, but app developers can also bring problems that look like their real work, minus the framework.

The Gilded Rose deserves a special mention. Emily Bache maintains a repository with starting code in many languages, Kotlin and Swift included, and the exercise is to add one feature to deliberately messy code without breaking it. It feels uncomfortably familiar to anyone who has inherited an app.

The relative time formatter is a good bridge into UI testing. The same habit of injecting a fixed clock is what keeps screenshot tests stable, as covered in the snapshot testing field guide.

What tends to go wrong

The most common failure is a kata that is too big. If the pair is still writing setup code when the timer rings for the third time, the problem is wrong for the format. The second is one confident voice steering every turn from the audience; the facilitator's job is to ask the pair what they think first. The third is treating the dojo as a hiring test. People only try new things in a room where failing in public costs nothing.

Questions

How often should a team run a dojo?

Once a month is sustainable for most teams and frequent enough for habits to stick. Repeat the same kata two or three times over a few months; the second attempt is usually where people notice how differently they approach it.

Does everyone need to know TDD first?

No. The dojo is a gentle way to learn it, because the steps are tiny and someone always knows the next one. Start with a prepared kata so newcomers see the loop before they have to drive it.

Can a coding dojo work remotely?

Yes, with a shared editor or one person sharing a screen and handing over control at each rotation. Keep the group smaller than in person, around six people, and make the rotation order explicit, since nobody can see who is about to speak.

Should we use our production codebase?

Not for a regular dojo. Real code drags in build setup, dependencies and opinions about existing decisions. Extract a small problem from it instead, such as a validation rule or a state machine, and practice on that in an empty project.