In the previous blog post, we discussed how programmers can use coding katas  as an effective way to engage in deliberate practice. The possibility of performing a coding kata all by ourselves is a huge advantage. It gives us time sans pressure to practice a skill or concept to perfection. However, practicing in isolation also has its limits. There is a lot of wealth in different perspectives. We learn from practice, but we also learn a lot from each other. Practicing in isolation makes it difficult to learn from others.

 

I have had this happen to me several times (and not just in programming, but in pretty much everything). Very often I'd feel like I truly understood some concept - until I had a conversation with someone smarter. That conversation would not only help me realize how little I had understood, but would also leave me that much richer because of someone else's point of view. This is the benefit of practicing in a group - especially a group of smart people. A coding dojo is a setting where we practice with a group of peers.

 

 

I like the fun aspect too. All work and no play makes Jack a dull boy. The very nature of our profession is such that we have to spend an enormous amount of time learning; so why not make it fun as well. Learning is energized when it's fun. But that's not the only strength of a dojo. We learn from the experience of others, and a coding dojo is the perfect setting for that kind of cross-pollination to happen. 

 

A dojo can be facilitated in many ways and there's no one size fits all. What's good for the group is what works for the group. But there are a few best practices which have worked well for others. I'll list some of them below to get you started.

 

 

The first thing you need is a bunch of excited programmers. Local user groups are one place where you could find interested programmers. If you are already part of one such as the Seattle Java users group or the London Python user group, then you could do the dojos in the user group meetups. Another alternative is to create a group with colleagues or fellow students. Personally I'd give first preference to user groups because they consist of developers from diverse backgrounds, and since the primary purpose of dojos is to learn - the more diverse the better.

 

Another aspect we need to consider about the group is it's size. I am not sure if there is a right size, but most people agree there's a sweet spot at about 8 - 12 people. A group of more than twelve participants may not be very conducive for a coding dojo because everyone won't get a chance to code and the volume of opinions opinions may drown out actual learning.

 

The right kind of physical setting depends on the size of the group and what's available. If the group is small - two to four people - then everyone can just huddle around a computer with a large monitor. But large groups need a projector and proper seating. Normally a conference room which can seat everyone comfortably works out very well. If that's not available, then a classroom or any open space where you can create the required setup will do. 

 

Once again, this depends on what the group is comfortable with. If you are doing a dojo on a weekend and everyone has time, then you can stretch it for a good six to eight hours of fun and coding. However, if everyone's meeting after a workday, then two hours is possibly the most you can code (even for fun) before getting maxed out. 

 

 

Like most things till now, the problem exercise too depends on the group, their experience and their inclinations. If the group consists mostly of novice programmers, then you can choose several small exercises to practice basic aspects of programming in that language. I'll strongly recommend the exercises we have here on programmr.com (Java, Python, Ruby, iOS, Android) for a group of novice developers.

 

Basic coding exercises won't cut it for a group of intermediate level programmers. For such a group I'll recommend the exercises put up by Dave Thomas on his coding kata website.

 

I'm not going to make any suggestions for senior devs, because they have a rather wide playing field. It ranges from complex algorithms to complex refactoring to creating frameworks. The only recommendation I have is to select something that's fun, challenging and appropriate for the time frame you are working with.

 

 

By now you should be fairly clear about the goal of a coding dojo. Now let's talk about how to best accomplish it. To start with we need to be sure everyone in the group understands what needs to be done; so a dojo typically begins with someone reading out the problem statement, followed by a brief discussion to clarify any contentious points. 

 

In most setups a special computer is dedicated for coding and the monitor or projector placed such that its visible to everyone. The coding begins with a random pair which comes forth from the audience and codes for about twenty minutes. The pair may either split ten minutes each for driving and navigating, or they may have the same person drive for the entire duration. It's important for the pair to be verbose and explain what they are coding to ensure the audience understands whats going on and to prevent overworked members in the audience from falling asleep. The audience typically watches them, understands what they are doing, but does not interrupt. 

 

Twenty minutes of coding, then gives way to a short discussion break. There's a little pitfall here. In my experience it's really hard to keep track of time. It's best to keep a timer if you don't want to deal with overruns. The pair stops once the timer rings, even if they are in the middle of a method. They go upfront in the room and answer any questions the audience might have. These discussions are usually where the meat of learning happens. Once the discussion ends (it helps to timebox these discussions as well, to prevent over-zealous developers from discussing the merits of tabs vs. spaces till everyone else drops dead on their laptops) the next pair comes from the audience and continues where the previous pair left. This goes on for the duration of the dojo. This simple format of coding and discussing goes on for the entire duration of the dojo. Long sessions will offcourse have food breaks.

 

Just like coding kata's, the aim of a dojo is not to complete an exercise, but to code, discuss, explore, and learn. A good session is one where developers leave having learned new techniques and best practices from their peers; not one in which they necessarily complete the exercise.

 

A good coding dojo session results in a lot of learning, but it also leaves a lot of open questions. For example someone from the audience may briefly discuss how they used the Flyweight Design Pattern to solve a problem similar to what is being coded. If you don't know what the Flyweight Design Pattern is, then you should make a note and check it out after the session. This is just one example. There will be lots code of discussions in the duration of the dojo which will present opportunities for further exploration. It helps to make a note of everything you'd like to learn more about and look it up while its memory is fresh in your mind.