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!

Post to Twitter

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:

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):

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!

Post to Twitter


© 2007-2009 Danilo Sato | Powered by Wordpress

Page optimized by WP Minify WordPress Plugin