Has anyone tried using cyber-dojo.com at a code retreat? I was thinking about using it on Saturday, and I wondered if anyone had any experiences to share.
My idea was to set up a cyber-dojo for each programming language, and distribute the ids, so people could choose to use it if they wanted. I think it's a useful tool since it lets you visualize your flow of red-green, and review your whole session during each retrospective. It also levels the playing field for when people don't know the same IDE or editor - everyone is forced to use just a very basic editor in a browser.
Thoughts?
Emily Bache
Tags:
Permalink Reply by Jim Hurne on December 7, 2012 at 2:23am I haven't tried it, but using cyber-dojo looks promising. Using something like this will almost certainly reduce the amount of setup time.
The only (minor) downside to using a cyber-dojo is that developers won't have an opportunity to practise using the normal tools they use on a regular basis. As professional software developers, we should be experts in our tools, so practising with them can be helpful.
I'd say give it a try and see how it goes! You can always change your mind (you can always abandon cyber-dojo if one or two sessions go badly). Let us know how it goes!
Jim++
Permalink Reply by Emily Bache on December 10, 2012 at 5:37pm Hi,
Thanks for your encouraging words! We did try out cyber-dojo, and a few other things, and I wrote it up in a blog post:
http://emilybache.blogspot.se/2012/12/global-day-of-code-retreat-20...
- Emily
Permalink Reply by Jim Hurne on December 12, 2012 at 10:31am Thanks for sharing! It sounds like using cyber-dojo mostly worked.
I'm still on the fence as to whether or not to encourage the use of cyber-dojo. It sounds like it did help pairs focus on their coding technique and it definitely provided valuable information to the facilitator and the pairs about how well the pair was applying TDD. It is also clear using cyber-dojo eliminated a lot of setup-related issues. This is certainly all good.
At a coderetreat that uses everyday tools (which is the common case today), I often observe developers learning a lot from each other about their tools. For example, it is not uncommon for a developer to learn some new tricks in Vim or Emacs that they didn't know before (it also not uncommon for a developer to see Vim or Emacs used to its fullest potential for the first time). These are good, practical leanings that can help developers to become more productive.
I think what it comes down to is what you want participants to get out of the coderetreat. If you want them to focus exclusively on the code and on TDD, then using cyber-dojo sounds like an excellent choice. If you also want to give developers the opportunity to learn ways of working more productively, then using everyday tools might be a better choice.
Since there isn't a clear "right choice," I'm might try alternating coderetreats between cyber-dojo and everyday tools, or asking participants to use cyber-dojo for a portion (possibily half) of a coderetreat.
Anyway, thanks for sharing! It was definitely a valuable experiment that I hope others will repeat.
Jim++
Permalink Reply by Emily Bache on December 13, 2012 at 8:14am One of the suggested challenges is "use a text editor" and using cyberdojo gives you that, so you can always use it just for the one session where you're using that challenge :-)
I've seen several times a java developer used to eclipse, pairing with a ruby developer used to textmate, and they struggle to pair program effectively, whichever of their two languages and environments they choose. For them, cyber-dojo lets them both be equally out of their comfort zone, and it leads to better pairing.
I'd have to use it more, but I think it would make people more likely to pair with people outside of their language/editor preference, and spread knowledge. I havn't been measuring, but I have a feeling the pairs in my code retreats havn't mixed and switched enough. I'm less interested in a few good Ruby programmers exchanging Vim tricks than the whole group getting better at pairing and TDD.
Emily
© 2013 Created by corey haines.
