So what is a coding dojo?  A coding dojo is when four to eight people meet once a week to discuss code and reflect on how to improve their craft of writing software.  Dojos are timeboxed sessions that last from sixty to ninety minutes with at least forty-five minutes of coding.  The remaining time at the end of the dojo is spent in a short Retrospective led by the facilitator.  Participants are encouraged to do the kata work together in pairs.

Emily also wrote a great book, The Coding Dojo Handbook, to help you start your own coding dojos.  In the book, she describes the four simple rules of all coding dojos.

  1. Cannot discuss techniques without code: this is to retain the dojo focus on topics that programmers (and testers) care about – code.
  2. Cannot show code without tests: since coding dojos are an exercise on how to improve with TDD, the programmers must write unit tests using an xUnit framework.
  3. Participants use katas to improve their skills: katas are short programming exercises that can be solved any different number of ways, but usually focus on one element of the TDD cycle.
  4. No code goes into production: this is to preserve the sense of safety essential for coding dojos since we want people to try practices they might not use in production code.

Here is a list of katas from Emily’s github site and another list of katas from the coding dojo site.  If you are looking for more katas, just do a google search on “coding katas” and it turns up lots of hits.

Of course, someone on the Internet decided to take the contrary position about the benefit of coding dojos and kata.   At least the author took time to craft some well-reasoned positions.