Cyber Dojo and Extreme Startup
Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over. While drinking and socializing, of course.
I found the format useful, and perhaps this blogpost will useful to others who would like to organize a coding workshop.
Part I: A longer introduction
In order to get people to have a shared vision of the activities of the workshop, we started slower than I’ve sometimes seen in other workshops. First, everyone in the room said a few words about what they were hoping to get out of the evening. Then, I demonstrated a simple exercise together with @karianneberg. In the exercise, we demonstrate how to do pair programming and test-driven development. After the demo, we discussed what aspects of this way of working were surprising or different from what the audience was used to.
Take-aways: Coding dojos often throw the participants out on deep water right away. By instead showing an idealized pair-programming session, we provided a model for the participants to follow.
Part II: Exercise
We started out with the simplest programming exercise I’ve been able to come up with: Calculate whether a year is a leap year. I took the instructions for of the exercise from @jonjagger’s Cyber Dojo tool. The participants worked in pairs on this exercise.
Cyber Dojo can be a frustrating tool, and I offered people the option to use it or not as they wanted. In the end, almost all the pairs chose to use it for the first exercise. And we could see how their work was progressing on the projector.
After everyone had completed the leap year exercise, we switched around the teams and worked on an exercise to translate Arabic numerals to Roman numerals. Here, too, I used the instructions from Cyber Dojo. However, due to various problems, we decided not to use Cyber Dojo as the programming environment for this exercise.
We did a brief retrospective after each exercise. I decided to mostly use this chance to ask “too much or too little questions”, like “do you feel it would’ve been faster if you’d taken larger or smaller steps?”, “do you think you refactored too early or too late”, “did you switch which person in the pair was using the keyboard too much or too little”, “did you spend too much or too little time thinking about how you would solve the problem”, etc.
Take-aways: Coding dojos usually practice a stylized form of programming with as small steps as possible. By reflecting on how it would be to work with the same problem in a less forced way, it’s easier for people to find out how they can apply what they learn to their day-to-day work. In particular, the discussion about how big the TDD-steps should be brought up a lot of interesting debate.
I usually try to have bigger exercises, like Yahtzee scoring or Poker hands. I found the smaller exercises to work very well for this workshop as this part ended up acting as a warm-up for the competition.
Cyber dojo experiences (mostly for Jon): I’ve used the Cyber Dojo a few times now. It’s an interesting tool, and I find Jon’s idea about taking away features to avoid distractions to be a good strategy in general. However, I usually find that to some level, the tool becomes a distraction because of its limitations. In particular, I think the groups would’ve wanted to continue using it if they didn’t have to work so with the build script and if they could’ve switched between files and run the tests using the keyboard. The groups miss code completion etc, but are willing to accept these shortcomings because of the community and competitive aspects of the tool. The real killer, however, was the setup. Using a Windows box, I didn’t get the Cyber Dojo to run natively. I tried using a VirtualBox setup, but kept running into technical problems. In the end, I decided to risk using Jon’s hosted dojo at http://cyber-dojo.com. Sadly, it turned out that Jon was doing upgrades of that system halfway through our dojo. Too bad, but as he provides this service out of the goodness of his heart, I knew the risks.
Part III: Competition
After the exercises, we had a competition where people got to use or ignore what they’d learned as they saw fit. The competition used the Extreme Startup workshop. There’s a lot to be said about it, and I’ll write a future blogpost on Extreme Startup.
Conclusion
Cyber dojo and extreme startup both create a competitive and social environment for small groups to practice programming. This can create really fun workshops. The Bergen Java User Group kept playing with Extreme Startup until midnight.
I will use Extreme Startup as a workshop in the future. Hopefully I will add more questions, too. I may use Cyber Dojo again, but I’m hoping for some changes to the software before doing so. As it is, there are too many aspects that distract the users.
Comments:
Johannes Brodwall - Jun 22, 2011
That’s good to hear. I think the basic structure of the Cyber Dojo works really well. It combines individual/pair work with a social aspect with the dashboard. Some of the feature sparseness removes distractions, but some add distractions, too.
[Jon Jagger] - Jun 21, 2011
Hi Johannes. Thankyou for the feedback. I really appreciate it. After discussing with a few friends I’ve decided I’m going to introduce a few keyboard shortcuts.Â