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!

I’m here having a great time in Chicago, at Agile 2009. I will write more about the sessions in later posts, but I wanted to talk about the Coding Dojo we ran at the Open Jam. Organised by my friends from the Dojo@SP (thanks Hugo, Mari, and Thiago!), we tried a projector-less format that went really well. I wrote about the Kake Format a while ago, although the name changed.

It was a lot of fun, and we were lucky to bump into Emmanuel Gaillot around in Chicago, who made it to the session as well. We solved the Kata Bowling in three different stations: one in Ruby, one in Haskell, and one in Java. The code is available on GitHub, and these are some pictures I took during the session:

If you want to try out a dynamic format, where people have more chance to participate and train different skills, and you don’t have a projector available, I urge you to try out the Kake Format on your Dojo and share your experiences!

XP 2009 is happening between 25-29th of May in Sardinia, Italy and I will be there attending and presenting some interesting workshops:

• The Lean Lego Game: Me and Francisco have been improving our workshop since we last presented it at Agiles 2008 in Argentina, and we will be presenting a long version (180 minutes) on Monday, May 25th. We have just a few “seats” available to participate on the session (20-24) and it will be occupied in a first-come-first-serve basis. If more people show up we have plans to try and not reject anyone, though.

• Test Driven Development: Performing Art: Emily Bache kindly invited me to present a Prepared Kata at her workshop and I will be pairing with Francisco for 30-40 minutes, programming in Ruby with RSpec/Cucumber. Should be fun to “perform” and watch the other pairs as well. Looking forward to that session on Wednesday afternoon!

My fellow ThoughtWorker Pat Kua will be there presenting a workshop as well. I will try to brush up my (lately lazy) writting skills and publish some conference reports. And hope to see you all there in Sardinia!

Since last December, my friend Ivan Sanchez invited me to help him organize a Coding Dojo in London, at Skills Matter. We’ve only had a few sessions so far, but it’s been great fun going to regular Dojo sessions again, since I left Brazil 1 year ago. In the last session, I did a prepared Kata in Ruby, using RSpec and Ivan did a great job of summarizing some of the lessons learned in his blog.

Our next session will be next Thursday, February 12th and you have to subscribe on the Skills Matter website if you want to attend. To join our discussions of which problems to tackle, which languages to use, join our mailing list. We’re also publishing the source code from the sessions on Github, and some of the sessions are being published as podcasts/videos on the Skills Matter website. I hope to see some of you on Thursday!

I’m back from a 2 week “conference season” in Brazil and Argentina, but before I share my experiences on those conferences, I want to talk about my first session at the São Paulo Coding Dojo since I left in February. It was very unusual and pleasant for different reasons: first of all, George had arrived in Brazil for Rails Summit Latin America and I took him to the session; second, it was held at one of the participant’s house, instead of the usual venue at the University of São Paulo (which made it possible to add a taste of fresh baked pizzas to the retrospective); third, we decided to try out a different session format called, in lack of a better name, ÃœberDojo which I will try to describe in this post. Hugo has already explained how they came up with the new format in his blog.

In an ÃœberDojo, the setup is different than a regular session: there are more than one laptop and no projector. The number of laptops may vary depending on the number of participants, but we were 14 and decided to have 4 pairs, so 4 laptops were available. We laid out the laptops in 2 tables and chose 2 different problems to be solved in 2 different languages. We would go with Python and Ruby, but George argued in favour of having different programming paradigms to enrich the discussions, so we ended up coding in Ruby and Haskell. The problems we chose were already familiar to most of the participants since the goal of the session was to try out the new format rather than solving a difficult problem or learning a new language: Minesweeper and Bank OCR were the chosen problems.

The dynamics of the session are similar to a Randori session, but with multiple pairs coding at the same time. We used a fixed timebox of 7 minutes to switch the pairs (when the round is over, the driver leaves the pair, the observer becomes pilot, and a new observer joins from the audience). The big difference in this format is that it’s impossible for everyone to follow the same train of thought, and there’s always more people than seats available so there’s a lot more chatting happening. When a new member joins the pair, it’s very likely that he will have almost no previous experience with the code being developed (similar to a real-life environment?), so everyone can exercise their ability to read and write readable code. In the original idea, people who were not coding were not supposed to follow what the other pairs were doing, but we ended up helping other pairs with less knowledge on the languages and/or environment. I have to admit I sometimes tried to stick around one of the pair stations because the approach to the solution and the discussions were getting interesting :-)

At the end we held our usual retrospective with food (a lot of pizza) and everyone seemed to have enjoyed the session. I particularly felt the energy and the innovation happening and was very excited with the results. We coded for more than 1:30 hours and it was very hard for me to leave the code unfinished. Although it was a lot of fun, I think for this kind of session to be successful, the participants need to be familiar with a Dojo session and its dynamics (TDD and Pair Programming in particular). Hugo was also a very good moderator, using a pairing matrix to keep track of who was pairing with who, to keep at least one experienced member on each pair, and to put different people in different pairs at each round. The code from that session is available at GitHub.

I see some benefits to trying out this type of session. Solving the same problems in different languages (and paradigms) made it possible to have a rich discussion at the end. For example: when solving the Bank OCR problem in Haskell, pattern matching made it easy to make progress on the first steps, while the Ruby version was getting stuck with a lot of nested if/else statements. Another benefit of this type of session is that you can cope with programmers in different levels of experience. In a traditional Dojo session, you always go as fast as your least experienced participant. In this session, you have different streams of development happening at the same time, so a faster pair can make more progress on their turn. Finally, I think this environment is much more similar to what you might encounter in “real-life”: you develop code for others to read and you have to understand what others were doing while you were absent.

I hope you try out this format in your Dojo and share your experiences. What other types of session are you trying out in your local Dojos? Would you have a better name for this new session format? Leave your comments!

This is a common question that usually comes up when I talk about Coding Dojos, that I found it would be useful to share it with everyone:

“Where can I find problems to solve on my Coding Dojo?”

At the São Paulo Coding Dojo, we tend to choose problems from different sources, and we keep track of the sources in a wiki. Since this page hasn’t changed for a while, I’m publishing the current version here so others can benefit:

• Coding Dojo Wiki
• Ruby Quiz
• Code Kata (Dave Thomas)
• Programming Challenges
• Top Coder
• UVa (link 1, link 2)
• SPOJ
• TDD Problems

The list is not supposed to be exhaustive, but there’s quite a lot in there to keep you busy for a while. I should highlight that both UVa and SPOJ accept code submissions so you can get feedback about whether your solution works or not. SPOJ, in particular, accepts a wide variety of languages (such as Ruby, Python, Java, C, Brainf**k, and even Whitespace)

For those interested in starting a Coding Dojo, there are some easier problems that we usually use when the audience is new to the whole Dojo concept. Also, they are not hard so the focus is not on solving the problem, but actually learning the interactions and flow of a Coding Dojo session (TDD, pair programming, or sometimes to learn a new language):

• Roman Numerals
• Bank OCR
• The Blocks Problem
• Minesweeper
• Bowling Game

I hope this is helpful and, for more information about the São Paulo Coding Dojo, follow our blog, join our discussion list (for the Portuguese speakers), read our paper or some of our session reports in the Coding Dojo wiki (in English). Enjoy!

The main reason I went to the conference was to present my experience report on Wednesday about running a Coding Dojo in São Paulo since last year with my friends: Hugo and Mariana. I just made the slides available for download, as well as the published paper. Feel free to comment and send questions and comments about our unanswered questions.

The overall feedback we got from the 30 minutes presentation was very good and we decided to do a Live Dojo at the Open Jam in the next available slot. Besides me, Hugo, and Mariana, Emmanuel and Arnaud from the Paris Dojo showed up, Ivan Sanchez from the Floripa Dojo as well, and other people joined us during the session.

We did a Randori session solving the Blocks Problem in Ruby/RSpec, switching pairs every 7 minutes. Although we didn’t finish the problem, it generated some interesting discussions about exposing the internal state vs. a representation of the state to the tests, and how valuable it is to introduce a data structure that you don’t need now but will soon need.

The problem generated some interest and, on the following day, Arnaud had scheduled a slot on the Opem Jam, and we decided to tackle the problem again, but this time in Haskell. Dan and Liz were also there and it was really cool to see the same problem from a different perspective. We discussed how some features of a functional language forces you to think in a different way (I still don’t quite understand Monads, by the way) :-)

Another interesting learning point was: In our paper, we discussed a whole topic about issues with people pairing in different environments (operating system, keyboard layout, shortcut keys, IDEs, …) at every meeting. At the Open Jam, Dan proposed that we used a local Mercurial repository to share the progress on development (pushing at each TDD step for the next pair to continue working on the problem). This allowed him to work on his Mac with a Dvorak layout, while we were using Emacs on a Linux laptop. The other benefit of this approach is that it allows people to experience how Continuous Integration works in practice, committing as often as possible, whenever it makes sense to do so. Good stuff!

For those of you who didn’t know, after going to XP 2007 last year and speaking with Emmanuel Gaillot, I decided to start a Coding Dojo in São Paulo, Brazil. We’ve been running weekly sessions since last July and after I moved to London, Mariana, Hugo, Fabricio, and others are making sure that the Dojo continues. It has been very fun and educational to organize and run the Dojo, so we decided to share our experiences with the community. We are proposing a 30 minutes Experience Report to be presented at Agile 2008. I wanted to submit this proposal earlier to allow more time for feedback and reviews, but the bureaucracy of moving to another country and the excitement of working with very talented people has kept me busy. But the deadline for submitting session proposals to Agile 2008 is tomorrow, and I didn’t want to lose the opportunity of attending and sharing our experiences. We would appreciate any feedback to improve our session. The link to the proposal is here. Thanks!

 

Esse fim de semana tive a oportunidade de conhecer o Rio de Janeiro e participar do Rio on Rails, organizado pelo pessoal da ImproveIt. O sábado foi repleto de Ruby e Rails e no domingo tive um tempinho para passear e conhecer um pouco da cidade maravilhosa.

 

 

Os organizadores estão de parabéns. As palestras foram muito bem escolhidas e acho que deram um bom gostinho de como é divertido programar em Ruby e Rails para quem nunca tinha experimentado. Como sempre, eventos são uma excelente oportunidade de conhecer gente nova e trocar experiências e o Rio on Rails não deixou a desejar. Conheci o Ronaldo Ferraz, que falou um pouco sobre DSLs, o Demetrius Nunes, um dos pioneiros na adoção de Rails no Brasil, o Eduardo do site o Curioso, todo o pessoal da Improveit e do projeto Lucidus e mais um monte de gente que não vou lembrar do nome, mas que estavam presentes para fazer mais um grande evento da comunidade Rails no Brasil.

 

 

Minha palestra sobre BDD e RSpec foi uma evolução da palestra no RejectConf’SP. Com mais tempo para explicar os conceitos e fazer uma demonstração mais calma, acho que consegui passar uma idéia melhor da experiência de programar com BDD em Ruby e Rails. Os slides já estão disponíveis aqui, assim como o esqueleto da aplicação demo que desenvolvi, com o passo-a-passo da demonstração. Quem quiser também consegue pegar a versão final do código apresentado.

 

 

Uma coisa legal que eu consegui terminar de preparar para a apresentação foram algumas das novidades do RSpec 1.1.0, como o Story Runner (integração com o RBehave, que eu apresentei no screencast do Dojo@SP), os plain text story tests e o protótipo do editor de story tests no browser.

 

 

Para rodar os exemplos, você precisará do Rails 1.2.6 (não fiz update pro 2.0 na palestra pois o patch da integração do RSpec com o Rails novo saiu na sexta a noite e não quis arriscar a demonstração ao vivo), do RSpec e do Rcov, caso queira verificar a cobertura (gem install rcov). Quem gostou da integração do Autotest com o Growl que eu usei na demonstração, pode pegar meus arquivos de configuração no Google Groups do Dojo@SP (não esqueça de instalar o Autotest com ‘gem install ZenTest’).

 

Na reunião do Dojo@SP do último dia 03/Out decidimos gravar um screencast do Kata que estávamos resolvendo: Splitting the Loot. Nessa reunião, eu apresentei um Kata Preparado, programando em Ruby e utilizando RSpec+RBehave como frameworks de BDD. O resultado está finalmente disponível no Google Video:

Depois da conversão, a qualidade do vídeo acabou sendo prejudicada. No tamanho original dá pra assistir, mas as letras ficam pequenas (principalmente quando mudo pro terminal). Os atalhos de teclado (gravados com o KeyCastr) também ficam ruim de ver.

Para assistir uma versão com resolução melhor, disponibilizei o arquivo original para download no site da AgilCoop:

• Dojo@SP Screencast #01 (1h33min / 266Mb)

O código final dessa e de todas as nossas reuniões pode ser obtido no nosso Google Groups.

Gostaria de agradecer a Mariana Bravo por ter criado nosso logotipo, o Paulo Sacramento, por ceder a música Batida Urbana sob a licença Creative Commons – Atribuição-Uso Não-Comercial 2.5 Brasil (utilizada na introdução e no final do vídeo) e aos participantes da reunião pelo feedback e ajuda na resolução do problema: Breno Franco, Daniel Cordeiro, RBP e Thiago Colucci.

Espero que esse vídeo ajude a mostrar como o Dojo funciona. O feedback de vocês é muito importante. Caso o retorno seja positivo, podemos produzir outros vídeos semelhantes. Se você se interessou pelo Dojo@SP, junte-se a nós!