While I practice code Kata for a few years now, for multiple good and bad reasons I never attended a Coding dojo. But as it's an experience I really want to have, I decided a few weeks ago to facilitate one for my colleagues during our lunch time.
Today was the day. And as tomorrow might be the end of the world (hmmm...), it's also the day I start blogging so that I can share the outcomes of my first dojo.
Today was the day. And as tomorrow might be the end of the world (hmmm...), it's also the day I start blogging so that I can share the outcomes of my first dojo.
Building up the Dojo
Working for the same company for a few years now, I knew most of my colleagues are far less into XP-Craftsmanship-Agile-yourPreferedFancyNameHere practices than I am. And here comes the first lesson I learned from this dojo : people are changing. I was counting on 4 participants, 6 in the best case scenario, but 12 showed their interest less than one hour after I sent my invite !
Unexpected interest means unexpected work for me : some of them asked me "What is a coding dojo ??" before deciding to attend. I didn't originally plan to introduce Coding Dojo per se, but it became obvious that it was necessary.
Time to put some structure on the knowledge I have about coding dojos. Time to vote with my wallet, too. For months, I was planning to buy Emily Bache's book "The Coding Dojo Handbook", the timing seems perfect. It didn't disappoint me : it is a valuable resource when you have to introduce coding dojo as a practice, ... and an invaluable one when you have to facilitate a dojo with no personal experience at all !
So I took a few hours to draw a few introductory slides, my goal being not to spent more than 10 minutes on the subject during the event. I drew some additional slides to introduce the kata itself and the tool we'll use, -Cyber-dojo, and I was ready.
Second personal benefit, written structure of my unstructured knowledge.
Entering the Dojo
Today, noon. No more I, it's times for We.
We started 15 minutes later than planned (next time, we should think to order sandwich for everyone), but as we managed to go over the Coding Dojo whats, whys and hows in 10 minutes (yes !), we'll have our 60 minutes of coding ! So we started a Randori in Pairs in a plain text editor (cyber-dojo) on one of the simplest kata, Fizzbuzz, in Java.
And the fun started ! Not that intellectual, conceptual fun, no, the real one. Smiles, laughs (lots of), kind teasing flying across the room, passionate discussions,... To be honest, I wasn't expecting that : we were like kids left alone in a toy shop ! Yeap, a coding dojo can be that funny !
Technically speaking, this coding session was a mess : it struck me after a few minutes (as facilitator, I was passing from one pair to another, to guide and observe) that at least half of the attendants were not at ease at all with TDD, and all of them didn't get into the Babysteps way of coding. God ! Some of the katas progressed in such terrible manner that we all have to laugh when the time came to review everyone code !
Leaving the Dojo
We laughed because we all knew that we were actually learning a lot on our coding practice ! We used the One thing that surprise you - One thing that you learned - One thing you plan to take with you technique to run our retrospective.
As you can guess, fun we have was the most surprising thing. Our dependency on our IDE (someone confessed "ashamed" he had to googled ... String API !) was a surprise, too. Unexpected too, the number of things one can actually learn by playing with an algorithme as simple as Fizzbuzz.
The list of things learned during this hour is pretty impressive. In no particular order :
- Vocabulary related to Coding dojos
- Red-Green-Refactor principle (!)
- Baby-steps principle
- One assertion per method
- Tests should cover all cases, but it doesn't make sense to test all possible values
- There are multiple ways to implement the very same tests
- Computation of method complexity (this one really came out of the discussion we have when reviewing implementations)
- There is a better use of our corporate Sonar reports than the one I have (same remark as above)
I obviously don't know what my coworkers wrote on their One thing you plan to take with you post-it. But I've seen that all them had written two or three lines, ... and none forgot it in the meeting room.
Going home
Honestly, I knew that during our dojo I'll be the master-in-the-room. But i found astonishing some of the things learned : Red-Green-Refactor principle ? One assertion per method ? Computing complexity of method ? Meaningful tests ? I've talk about all of these since years ! Aren't there examples of all of these in my code ?
I talked and did, but it seems that I should have listen too. There was another striking moment : whilst they were closing their laptop, before I started the retrospective, one of the attendant immediately asked for more dojo, the sooner the better. Knowing what he learned and was surprised by, it clearly appeared to me that talking and doing serve no purpose. Teaching does !
THAT is the thing I've take with me after this dojo.
Comments