Coding Dojo - Kake format

room: Gamle bybro (capacity 40) — time: Friday 13:45-14:30, Friday 13:00-13:45, Friday 15:00-15:45, Friday 15:45-16:30
Level: Practicing

Most Coding Dojos follow 2 main formats: Kata and Randori. Both formats try to give as much information as possible to the audience by evolving solutions from scratch. This is great when dealing from Novice to Competent level but tends to get slightly less interesting to people at a higher level. The Kake format goes beyond competent by adding an extra challenge. It increases dynamics by putting people into a more “real” world exercise. Participants deal with unknown code bases and have to evolve from them. This clinic will present the format and initiate a real session with the attendees.


The session will use n computers given that n is between #attendees/3 and #attendees/5. One laptop will be provided and it is expected that at least one of each 5 attendees have a laptop available. There will be at least two pen-drives containing environments to develop Java, Haskell, Ruby, Python and Javascript in GNU/Linux, Windows and Mac OS X for attendees accepting to use their own machines. This default setup can happen during the presentation preceding the activities.

The session will start with a 20 minutes presentation about Coding Dojo and the most traditional formats used in those practices. Focus will be given to the goals and objectives of each format and present the differences with the Kake format and points people should be careful about.

The next 10 minutes will be used to introduce one previously chosen code kata (from the following websites: TDD problems, Code Kata and Coding Dojo Kata Catalog). A description of the kata will be handed over to each attendee to help them remember their goals during the session. Attendees will then be asked to choose which languages they would like to work on by voting. They will select at max 5 languages to be distributed between the laptops and there should be no problems if languages repeat themselves since solutions will probably differ if there are many attendees.

The next 100 minutes are destined to run 12 rounds of 7 minutes each in which n pairs will be working on the computers to evolve the solution of the problem attributed to that specific computer. The extra 15 minutes provide some slack to switch pairs and fix any technical issue that might happen. The pairs are constituted by a pilot (person handling the keyboard) and a co-pilot (person helping to find bugs, giving suggestions and helping improve the readability). The rest of the attendees will form the audience. General organization can be seen in the image below:

Workshop layout

This audience will be able to discuss possible solutions to the problems, talk about their experience with the code or contribute to the retrospective. During the whole session, yellow, red and white post-its will be available so that people can report what they learned or liked (in the yellow ones) and what they felt could improve or could have been better (in red ones). The white ones are used to suggest discussions about some problem or diversion that happened during the session.

Once the round is over, the pilots go to the audience, the co-pilots assume the keyboard and people from the audience assume the co-pilot roles in a computer they have not yet been with people they have not yet coded with.

If there are more people in the audience than coding, we will use Emmanuel Gaillot’s suggestion to assign an observer role to n people. Those observers will have to chose the computer in which they will work on the next round. They are not allowed to interfere in any way but can start to understand the current situation of the code. It allows attendees to feel more comfortable once they start working on the code. Those are represented as faded circles in the following overview image.

People in the audience can use the 7 minutes to rest, talk to other attendees about their experiences and add post-its to the retrospective wall.

Once the coding rounds are all over, each person who started the solution in each computer will be given from 3 to 7 minutes to walk the whole audience through the code. It is expected that a few codes will be very hard to present while others will probably be a bit easier but surely most of them will be very different from what the person had imagined at start.

The remaining time will be used to have a retrospective of the session. The presenter will read out loud and group the accumulated post-its and the biggest groups will be discussed by the attendees.

Learning outcomes
  • Effective pair programming
  • Breaking in small goals
  • Dynamic TDD
  • Working with someone else’s code
  • Importance of clean code
  • Benefits from transmitting intention in the code
Featured participants
Primary target persona

No reviews

Subscribe to an RSS feed of reviews of this proposal Syndicate content