This session was a mix of talk and coding dojo, in order to give a hands on experience following the rest of this conference’s approach. As a result, this 45-minute dojo became the shortest coding dojo I’ve organised so far.
It was also the first time I’ve tried to start a dojo with an existing piece of code. This code was simple, incomplete, naive and desperately asking for refactoring. It helped keeping the session flow since the first minute, mainly because it took only a couple of seconds for the first pair to learn the code and figure out ways to improve it.
One fact that surprised me as well was how most of the 20 people present was afraid of participate. Being at a craftsmen conference and knowing the benefits of the coding dojo, I really expected people would compete for a chance to show their skills. At our regular dojos people work in harder problems and new languages and still don’t get intimidated. Well, maybe it takes some time to overcome the fear of coding in public.
This session also confirmed my theory that the Minesweeper problem is really one of the best to introduce a coding dojo to new people: it involves simple algorithms, simple data structures and has plenty of room to apply basic OOP and TDD techniques.
Finally, here are some other resources from the session:
- Slides (quick introduction to coding dojo + randori rules)
- Minesweeper problem description
- Source code - initial and final code generated at the session; download and keep playing with it.