Coding Dojo Primer


I have been spurred on to write a blog about coding dojos by a double coincidence of wants: recent requests for information and my own thinking on the matter during some great dojo practice sessions with a good coding buddy of mine, a sensei of source code (he knows who he is!).

What is a Dojo?

This is a term that derives, as with many things in Lean and Agile, from Japanese martial arts training. It is a place where students gather to train under the watchful eye of a master. Well that is what we have interpreted and inferred but as barbarian westerners we have pretty much mixed up the place (dojo means "place of the way") with the practice and could get into some seriously ill advised altercations with true students of martial arts. All that being said, for better or for worse, the term has been appropriated and the next question is

What is a coding Dojo?

I first heard about coding dojos back around 2005 when I read what Laurent Bossavit had to say: «If I want to learn judo, I will enroll at the nearest dojo, and show up for one hour every week for the next two years, at the end of which I may opt for a more assiduous course of study to progress in the art. Years of further training might be rewarded with a black belt, which is merely the sign of ascent to a different stage of learning. No master ever stops learning. If I want to learn object programming... my employer will pack me off to a three-day Java course picked from this year's issue of a big training firm's catalog. Nuts to that -- acquiring coding skills is not an "instant gratification" process.»

This lead me to finding out about the roots of the dojo in Paris (the Paris dojo is still run weekly and has inspired other long running dojos around the world). I made the aquaintance of Emmanuel Gaillot at the Benelux Agile Open. Emmanuel had kicked off the first coding dojo in December 2004. Among other things he is also a founder organiser, with some other truly Agile people, of the French Agile Open for francophones. He is an engaging person and I always love meeting him and seeing what he is up to because it is always going to be interesting.

I loved the idea of dojos straight away. The Coder's Dojo offers a way of teaching and learning programming in a more appropriate manner, respecting the depth and subtlety of the craft. A Dojo is a weekly meeting between programmers of varying skill levels. They come together as equals - in physical, not virtual space - around an ongoing series of coding challenges called "code kata". It is a very old way of learning and practicing. Some suggest even older than the socratic method (but that would take up the whole blog to discuss).

I immediately started implementing them with teams I was coaching and recommending them to all other coaches and programmers I knew who were trying to fill the practical reality gap created by surface level, trendy Agile. It provided a perfect way to introduce TFD/TDD (Test First and Test Driven Development) and pair programming. It also provided a mechanism to build on programming skills in a non-threatening and stress-free way because it was decoupled from the pressures of work. Much to my delight they took on a life of their own everywhere I seeded them. Developers are quick to realise the power and elegance of the practice.

It might help you to understand why this is such an attractive way if you realise that many programmers consider coding to be a constantly developing craft. They realise that you have never finished learning and that you can learn useful things from other practising adepts. We recognise that, as in many fields, there are journeymen and masters. Watching a master at work and sharing with other journeymen motivates and inspires many of us to continue perfecting our craft and exploring our art.

Kata and Randori

There are two sorts of Coding dojo: Kata and Randori.


This takes the form of a rehearsed session. That is someone has worked a problem through and demonstrates during the session. Note: they work through the problem again from scratch they do NOT walk through imported code!

Here are the kata rules (probably I adapted them from Laurentís) that I advise:

  • Rehearsed: the solution is rehearsed beforehand by a coder or preferably a pair of coders
  • Choreographed performance: the coders re-create the solution during the session using TDD and pair programming.
  • Interactive : the Group can comment on design and coding style and can suggest improvements.
  • Continuous improvement: the group creates the solution that it feels is best, clearest and simplest
  • Leisurely: there are breaks for design reviews and discussions (and coffee is almost obligatory)


This has not been rehearsed and the group as a whole works through it. Think improvisational performance with audience participation.

Here are the randori rules (adapted from Laurentís) that I advise:

  • Improvised: the problem is introduced at the beginning of the session and the whole group attempts to solve it in real time using pair programming and TDD.
  • Pairing: group all take turns at the keyboard for about 5-7 minutes as pilot and co-pilot.
  • Interactive : the Group can comment on design and coding style and can suggest improvements.
  • Continuous improvement: the group creates the solution that it feels is best, clearest and simplest
  • Leisurely: there are breaks for design reviews and discussions (and AGAIN coffee is pretty much obligatory)
Here is a sample agenda for a dojo
  • 4:00 - 4:05 Introduction to the challenge
  • 4:05 - 4:10 Preliminary design session
  • 4:10 - 4:30 Code
  • 4:30 - 4:35 Design review and adjustment
  • 4:35 - 4:50 Code
  • 4:50 - 5:00 Retrospective and challenge for the next meeting
Some general rules for the dojo (I have been using these for ages and probably got them originally from Laurent or Emmanuel and adapted them)
  • There is a coding challenge that is announced beforehand.
  • There is a room with one computer attached to video screen.
  • The presenter explains the coding challenge and starts the Randori with a pair from audience or chooses a co-pilot for Kata presentations.
  • One half of the pair is changed every 5 minutes if it is a Randori.
  • The pair on the keyboard should continuously explain what they are doing.
  • The pair on the keyboard should stop when someone from the audience falls off the sled (has a question about understanding what the pair is doing) - and only continue when that someone is back on track again.
  • The audience should give comments on design only when there is green bar (All tests passed). During red bar (Tests failing - coding in progress) audience can only ask questions for understanding.
  • The pair should not continue writing new code if other participants are not happy with the current design. The existing code should be always well refactored before starting to write new code.
  • The pair will use TDD (Test-Driven Development).
  • All produced code will be made publicly available
  • The programming language to be used is announced in advance of the session.
  • The maximum number of participants is limited to 15.
  • The presenter acts as a product owner
  • The actual coding is done in small iterations. There can be short planning periods before every coding iteration.

Useful Links

Blog Home Page