XP2010: Coding Dojo Open Space
I attended an open space hosted by Emily Bache at the XP2010 conference in Trondheim, Norway with several other people who have been organising coding dojos around the world.
It was really interesting to hear about some of the different approaches that people have taken and how a lot of the issues we had with the one we used to run in Sydney were the same as what others had experienced.
These were some of the things that I took from the session:
-
We talked about the difficulty of keeping up the enthusiasm/energy for a coding dojo over a long period of time and Emily suggested that one way to reduce this problem was to link the dojo with a group which met up for something else other than just a coding dojo. For example Emily runs a dojo with the Ruby and Python user groups whereby one week someone would do a presentation on something and the next week they would run a dojo. The one we ran was generally internal to ThoughtWorks so we had a different problem in that some people preferred a coding dojo and others preferred to hack on problems alone but with others around.
-
Another suggestion around this was that rotating the organiser between the group was a way to keep enthusiasm up and made it the whole groups' responsibility to keep the dojo running rather than placing the responsibility at the feet of one or two people
-
An idea suggested by Mariana & Hugo from their experiences running a dojo in Sao Paulo was how to introduce a new language in the dojo environment. They originally tried just running a randori style dojo but found that this didn’t work out so well if there wasn’t at least one person who had enough experience to at least know how to setup the development environment and write some tests in the language. The approach they took was to have one person do a prepared kata in the new language at the beginning of the session and then after they’d done that then the rest of the group would participate.
-
Another suggestion was to run a retrospective on each dojo session where people would write down what they had learnt from the session and what had hindered their learning. This strikes me as something which would be quite useful to consider even on a normal project, especially near the beginning, and would help us to at least recognise if there are factors which are preventing us learning as much as we’d like. We could then do something to fix that if necessary.
-
Hugo and Emily both suggested the 'Kake' format as one which might be better suited in a dojo with people who are quite experienced with the dojo idea. In this format there would be more than one computer being used and pairs would rotate between the stations. At each station the same problem could be being solved in a different language or a different problem in the same language.
-
I also learnt that we had misunderstood the way we were supposed to pair in a randori dojo. We somehow had the idea that the driver was supposed to drive for the whole 7 minutes and the navigator would just navigate during that time and then they would be the driver next time around. Emily pointed out that the idea is just to pair normally but have one person rotate after 7 minutes. This makes much more sense to me and would have made our sessions much more natural than they felt at times while we tried to follow this idea.
About the author
I'm currently working on short form content at ClickHouse. I publish short 5 minute videos showing how to solve data problems on YouTube @LearnDataWithMark. I previously worked on graph analytics at Neo4j, where I also co-authored the O'Reilly Graph Algorithms Book with Amy Hodler.