Experiencing a Coding Dojo
Last night I attended a Coding Dojo meetup organised by Matthias Noback of IBuildings. Since this is one of the things that I've always wanted to organise but never got around to at Procurios, I happily jumped at the occasion and visited the fruit of someone else's labour. This is a short report of the night.
I arrived at the IBuildings office in Utrecht amidst lot of pizza's :) Since I had had dinner already I skipped those but it was a good soft introduction to other people nonetheless. After some time Matthias took the lead and gave a short explanation of the plans for this night. Basically we were doing a Randori Kata approach and we were tackling a simple kata: the Yathzee kata. In short this meant pair programming but shifting driver/navigator pairs almost continuously (4m. blocks in our case) while working on the Yathzee kata. After this time driver becomes navigator and a new driver is selected from the audience.
Some observations
I think we started out a bit too quick. Therefor there was a bit of confusion for the first couple of pairs on the actual assignment. The audience that had time to read more of the kata assignment basically made a (correct) u-turn after a couple of pairs, deleting most code up untill then. The good part? Nobody got angry :)
The selected time period is very short. I think as a group we were not accustomed enough to babysteps for instance. I think this is mainly inexperience in hardcore TDD'ing and the Randori kata format. Since we're talking minutes here it might still be a good idea to adopt the suggested 5 to 7 minutes timeframe next time.
There was a lot of noise from the audience. This is part good since it means everyone was very much involved. Still it was also distracting and contributed to an already chaotic short period of programming. We had two coding sessions that night and by suggestion, the first was free-for-all talking in the audience while the second we tried to be absolutely silent. The first 45 minutes were way too busy (for me personally) but the second 45 minutes told us it is impossible (and sometimes improductive) to stay silent.
I like the suggestion of the audience only being allowed to talk at a moment that there are no failing tests in the testsuite at the Randori Kata overview page:
The audience should give advice/suggest refactorings primarily on a green bar. At other times the pair at the keyboard may ask not to be interrupted.
This means you are not interrupted while solving a problem, but when you're trying to figure out what the next problem is. That is exactly the time where the audience input might be useful.
Even though there are only a few rules it was still hard for us as a group to maintain them. The silence was hard to maintain as I mentioned before. Also TDD'ing was not applied continuously. Mainly code that got written before tests. I don't feel this is terrible by the way. We were inexperienced and learning after all. The question that remains for me: As a facilitator, should you crack down on the rules and maintain them very strict or is adopting a relaxed attitude to the rules more efficient?
Fun
Above all I had a lot of fun. I'm happy I finally got to experience a Coding dojo. I'm also happy it was with a facilitator and a group of people open to experimenting mid-session and evaluation. I'm sure next sessions will be even better. Thanks Matthias :)
After about 10 years of professional development at both