Danilo Sato

“A Coding Dojo is a meeting where a bunch of coders get together to work on a programming challenge. They are there to have fun and to engage in deliberate practice in order to improve their skills.” — Definition from codingdojo.org

I’ve participated and facilitated many Coding Dojo sessions since 2007 and people have been asking me this question many times that I decided to answer it in this post: How can I start a Coding Dojo and how to keep it engaging?

First of all, I would highly recommend the book “The Coding Dojo Handbook“ by Emily Bache. She dedicates an entire section for tips on how to organize a Coding Dojo. Instead of repeating her advice, I wanted to provide a few tips based on my own experience founding the Coding Dojo São Paulo and running sessions inside ThoughtWorks and at some of our clients.

Engage a small group of core members

It is important to create a cadence to the meetings and although having different people show up each time is good, I found it very valuable to engage a small group of core members that are almost always there. This creates healthy social pressure to keep things going and gives flexibility when one person cannot attend.

In the beginning I facilitated most of the sessions, but once the core team got used to the process we started rotating the facilitator role. This also meant that when I had to move to another country, the Coding Dojo did not stop. I knew I left it in the good hands of people like Mariana, Hugo, Thiago, and although none of us attend the sessions anymore, the Coding Dojo São Paulo is still alive and active. New people are running it in different locations throughout São Paulo and our mailing list has more than 350 members with new people joining every week.

Keep it fresh! Try out new ideas

Following the standard meeting styles is a good way to start. In Randori format only one pair codes while the rest of the audience follows along and the pair rotates every 5-7 minutes; In a Prepared Kata one person is coding all the time and presenting their solution while the audience follows along. These formats are simple but provide enough structure to have a fun and effective session. However, after a while, you should start experimenting with new ideas. This is how we ended up inventing the Kake style in São Paulo. A Code Retreat is another format that became very popular by Corey Haines.

Keeping things fresh doesn’t only apply to the format of the session. Try experimenting with variations on:

• Programming language
• Creating constraints: like following Object Calisthenics rules or using gigantic font sizes to avoid long lines of code
• Tools and environment: IDEs, text editors, operating systems, testing frameworks
• Design approaches: solving the same kata with different designs or algorithms

In summary, don’t let things get stale or boring.

Be welcoming and tolerant with new members

The Dojo should happen in a safe environment, and as a facilitator you need to create that safety. Be aware of people’s behaviors during the meeting to avoid things like: speaking over the pair, opening their own laptop and start coding in parallel, big bang changes to the code, rushing to complete the solution in their 5 minutes slot, or usage of language-specific idioms without explanation.

When I am facilitating the session, if there is one new person in the group, I always go through an introductory slide deck. It takes me only five minutes to present, but it sets the scene and expectations about what’s about to happen. I also reinforce the fact that they are not required to code and can simply observe. The only people that will code are those that are willing to do so. I cannot remember how many times I had new participants wanting to be observers and volunteering themselves to step up half-way through the meeting, once they get a sense of what’s happening.

Another strategy that I use is to put myself in “beginner’s mind” the entire time, and observe people’s body language during the session. If someone frowns or seem puzzled about something and they don’t ask, I will ask on their behalf even if I know the answer. Instead of just giving the answer or explaining what happened, I find that by asking the question I demonstrate the behavior I want to encourage. Human beings are good at copying others and once they see someone else doing it, they’re much more likely to do it themselves.

Find your group’s sustainable pace

As I mentioned before, meeting cadence is important. However, you should find the right cadence for your group. When we started the Coding Dojo São Paulo, we were so excited that we ran 2 sessions per week. After a while it became clear that this was a hard pace to keep up with, so we switched to weekly meetings. This has shifted over time between bi-weekly and weekly as the group of participants changed.

If you are running a Coding Dojo inside your company, depending on how much support you get internally, you can run sessions more frequently.

Another aspect of cadence to adjust is the duration of the meeting. I’ve participated in sessions that lasted 2 hours or more, but that might not be sustainable for your group. Too short and you don’t get enough time to learn. Too long and people get tired.

My advice is to experiment and gather feedback in the retrospective at the end of the session. In my experience the duration should be at least one hour, although 1:30h to 2:00h might be better. And weekly or bi-weekly meetings are the best frequency.

Prepare prior to the session

A little bit of preparation will help the meeting go smoother. Here are some of the things I’ve done to prepare:

• Have a pre-selected list of problems for people to choose from
• Decide on the format
• Make sure you have all the equipment you need (keyboards with different layouts, projector, adapters, post-it notes, etc.)
• Environment setup: create the project structure, have an initial skeleton for source files, make sure tests execute
• Order food: in longer meetings or after work hours, I try to get food ordered prior to the session to save time
• Have the introductory slides at hand
• Send a reminder e-mail confirming location, date, and time
• Engage key participants: if you’re trying a new language, find a language guru so she can assist during the session; if you’re doing a prepared kata, make sure the presenter is ready; if you want to share the session outcomes, find someone to be a scribe.

Respect the time

Finally, try to respect people’s time. This was especially hard in Brazil since we are all used to being late :-)

People who arrive on time should be rewarded with an on-time start to get the maximum out of the coding session. Also, respect the timebox when rotating pairs and don’t let the meeting run longer than you planned. As programmers, we are all passionate about making things work, so stopping half-way through a solution is not an easy ask. However, the goal of the Coding Dojo is to learn from each other and not to finish the entire Kata. I would much rather save the last 15 minutes for the group retrospective to discuss what we learned than having a few more rounds of coding without a wrap-up at the end.

Take action!

Hopefully these tips will help you get off the ground. We have just recently started a Coding Dojo at ThoughtWorks’ San Francisco office so I felt inspired to finally write about this. Let me know if you have more tips on how to run a great Coding Dojo!