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

Views: 315

Reply to This

Replies to This Discussion

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++

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

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++

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

Couldn't agree more. I've used Cyber-Dojo to good effect and found it solved a lot of problems, including the one you mention. Since it also "checks-in" every time you test, and provides a super-easy way to retreat to your prior green state (or any prior state) is makes "TDD like you mean it" and the 2-minutes-to-get-to-green "Taking Baby Steps" super simple.

Bob

We used it in a couple of the iterations last year and generally we didn't get a great impression of it since it was very basic, in terms of trying to use C#, since most of the .Net people were Resharper users.

Something I'd like as a change for Cyber-Dojo would be to flip around the creation of the session so that you choose the scenario first, and then have the option to choose any language when you join the session, that way the pairs could choose any language they'd like, rather than the organiser having to pick one for everyone.

Hi Duncan,

it is indeed very basic. That is deliberate. Features like resharper are a good way of going faster when you are creating software with the intention of shipping it. But in a practice session you are not creating software with the intention of shipping it! So what is the purpose? To practice! To learn. And by learn I mean something very specific. I mean changing your behaviour. If you do a practice and afterwards you all work in exactly the same way as before then the practice was a waste of time. To a great degree, the more you are "provoked" during a practice the better. There is no learning without provocation. 

You suggest you'd like each pair to be able to pick their own language. That they would find this more "comfortable". So that is exactly what they are _not_ allowed to do! Thus they are "forced", in a safe, obviously non-development environment, to face their underlying fears.

I find the best sessions are where there is definite tension in the room. Palpable energy. Switching partners during a practice session, for example, is something I find a lot of developers initially "resist". Their resistance is a sure sign it will be beneficial! 

Hope this helps

Thanks for the thoughtful reply, Jon!

Reply to Discussion

RSS

© 2014   Created by corey haines.

Badges  |  Report an Issue  |  Terms of Service