I’m not sure about your experience with coding dojos, but this is what happens to me every time I attend a series of coding dojos or organize one: the event is great, we have a lot of people there, do the exercises and schedule the next session. At the next event we have less people, but the atmosphere is still great, the next session is scheduled. The third event is different: only a few people show up, and even they only show up because it was scheduled. Something has changed, it is pretty obvious. In most of the cases developers complain that the exercises aren’t real.
One half of the complainers say that the simple exercises of the dojo aren’t real the knowledge they may gain, is not beneficial for their daily work. They want to work on the production code and not on a silly “fizz buzz” game. The other half kind of understands the concept, but they say that the setup is artificial. During the day they don’t really use TDD, they don’t work in pairs, they communicate differently and they have more time to finish the assignment. These techniques are supposed to show them a new way of working, but the change is too big and instead of cooperation they decide to resist. What about making this change a bit smaller and have a more realistic setup?
**The original idea of the coding dojos come from The Pragmatic Programmer book by David Thomas: developers should practice on small, not job related code base repeatedly so that they can master their profession like a musician. I’m a great fan of David’s work, so I don’t have any problems with the concept, but software developers aren’t musicians, at least not in an Agile/Lean environment: they are football players - the European ones. They have to practice and work together. At least this is what we teach them. Of course, musicians practice together too, but they learn their part alone and then they practice together.
In the individual pairs and randori coding dojo formats the developers are changing pairs or laptops, but in real life this doesn’t happen that often. What they change is source code. So the idea is to change the source code between developers during the dojo. The steps:
-
During the first session the participants get an exercise
-
They should work on the exercise alone
-
They should commit their changes to a remote branch (I suggest using git)
-
The next time, every participant should continue to work on somebody else’s branch
-
At the end of the session they should commit their changes to that remote branch
-
They should work on a new branch the next time
-
We have as much sessions as we need until we have a working software on each branch
This change simulates real life. If you do your job well, others can jump in any time and can work on your code - in this case your remote branch -, but if your code is not understandable and others have a hard time working with it, then there is something you can improve. During the sessions the facilitator should encourage the participants to talk when they don’t understand something in each other’s code, and should also give ideas to others when they implement something new. There is no artificial communication or setup, and no frequent changes, because this is how regular development is done.
This Friday we had our fifth session with the same participants, so we made some progress compared to the previous dojos. The participants had a really hard time understanding each other’s code so they realized that they had to work more closely together in order to use the time spent on the dojo on coding rather than reading and discussing. Additionally, participants could show each other new techniques, which was good because the initiative didn’t come from me - the facilitator -, but from the participants, which is more acceptable. I encourage you to give it a try, and share your experiences in the comment section below this post.
comments powered by Disqus