Danilo Sato

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!