Coding Dojo

Purpose

A Coding Dojo is a safe space for developers to practice fundamental skills: test-driven development, refactoring, design patterns, and working in small increments. By solving a kata (a well-defined practice problem), the team builds muscle memory without production pressure.

At a glance

How to run

1. Introduce the kata (5 min) — Present the problem. State the constraints (e.g., TDD required, no if-statements, 4-minute commit cycles).
2. Randori or prepared kata (70 min) —

• *Randori*: Pair at the keyboard rotates every 5–7 minutes. The audience guides.
• *Prepared*: One person demonstrates a solution step-by-step, explaining each decision.

1. Retrospective (15 min) — What technique did we practice? What did we learn? What surprised us?

Materials needed

• Kata description (e.g., FizzBuzz, Bowling Game, Roman Numerals, Gilded Rose)
• Projector or shared screen
• Development environment set up with test framework
• Timer for rotation

Pitfalls & common mistakes

• Choosing too complex a kata — The point is technique, not problem difficulty. Start simple.
• Skipping the retrospective — Without reflection, the practice does not transfer to daily work.
• Treating it as a competition — There is no winning; the goal is learning.
• Only doing it once — Regular dojos (weekly or bi-weekly) build lasting skills.

Inclusion & accessibility

• Choose a language and toolset the whole team is comfortable with.
• Welcome developers of all experience levels; the dojo is explicitly a learning space.
• Provide the kata description in advance for non-native speakers.

Variations

• Kata in a new language — Use the dojo to explore a new programming language.
• Refactoring dojo — Start with ugly code and refactor it step by step.
• Constraint-based dojo — Add constraints: no mouse, 2-minute commits, no primitives.
• Code retreat — Full-day event with multiple rounds, deleting code between rounds.

When NOT to use this

• If the team is in a delivery crunch and has no slack — but consider that investing in skills reduces future crunch.
• If the team views it as a waste of time — demonstrate value with a well-facilitated first session.

Source & further reading

• Bache, E. (2013). *The Coding Dojo Handbook*. Leanpub.
• Beck, K. (2002). *Test Driven Development: By Example*. Addison-Wesley.