I recently attended my first coding dojo – which was essentially the first time I’d been involved in programming something with others since, well, my university days.
A coding … what? Something Japanese – martial arts sounding. On being invited to this event I attempted to figure out what it was I’d been invited to, but first it gets worse. On the mailing list where this event is organised, I discovered that since no-one had volunteered to do it Kata style, we’d be doing a Randori Dojo. Upon reading the associated link I added Fishbowl discussions to the list of things I have no idea about – I’m sure you can imagine what a long list this has become through my lifetime.
Ah, now I think I’ve got it! The exercise goes a little like this – you sit trying to code whilst people break concrete bricks over your head – Shaolin monk style. I wonder how much my coding abilities will be enhanced by repeated concussion.
The slightly less bloody but more truthful version is that a Dojo is just a name for a group doing a coding training exercise (thus the martial arts references begin). A Kata is a prepared demonstration given by one individual to the group – the group presumably learns from the presenter’s approach, design and technique. The Randori format rotates each person attending through 2 programming (pair-programming) positions – 5 minutes in each spot.
Concrete bricks
I got a few things out of attending the Dojo: test driven development in action, complications and just how little code gets written in 5 minutes.
TDD – given the nature of the event, most people were pretty heavily influenced by the TDD kool-aid. However some of the little jibes “…ah, changing the test to match the code – brilliant!” helped to clarify in my head that ‘must write tests first’ actually means there’s no point writing tests that match your already written code – that is, write tests independently.
Complications – it was very difficult for some people to focus on the actual minimal details of the BankOCR training exercise and as an undirected group – well, let’s just say we went wandering off the map – people were worrying about classes that could validate their own input. It was the perfect illustration of the need to ruthlessly keep things as simple as possible (KISS) rather than trying to future-proof – there is no future, it’s a training exercise. Watching people use elaborate justifications in order to validate the one true path was jaw-dropping.
Benefits of concussion
Given that the final code was crazily wide and wild, it’s worth remembering that the point of doing ‘coding training’ like this is to learn something that can improve your real-life coding. I gained some confidence in my abilities by coding in front of full-time professionals. I learnt how much developers love the logical thinking tangents involve – and how dangerous this is when you actually want something done.
Doing it again
This was a first-time Dojo for many of the people who turned up, which made things a lot less productive than they could’ve been. I’ll definitely go back as I understand that as the group gets more cohesive, I can expect to learn more about programming techniques and gain more useful perspectives from the different approaches.
Related note: impressions from the guy who ran the show – http://isanchez.net/2008/12/05/impressions-of-the-first-open-coding-dojo/ (Yes, it takes me 7 weeks to write one post).
