Coding Dojo How-To

Getting started with coding dojos

It has been two years since [my first coding dojo as an organiser]({{< ref "posts/my-first-coding-dojo-as-organizer" >}}). I probably organised four or five more of such events since. This is not a lot but it has been sufficient to raise some interest at my current tech company. Other teams heard about it and are jumping on the wagon. Some asks questions, some do not and start in their own style. For the first category, here are some advices about how to start, from my own experience and colored by my own opinions (maybe you will disagree sometimes).

Learn the basics yourself

You could say "hey, let's try this dojo thing and see how it goes", but you would risk to miss convincing your audience if people are not as curious and enthusiastic as you are. For that very reason, because I want to have immediate and strong impact, I prefer to get prepared and light up the path.

Have some TDD experience

You probably do not need much when your audience is not familiar with TDD. My first dojo as an organizer was a few month after a global day of code retreat. I remember I was kinda noob with TDD by that time. I tried some simple katas at home after that, got hooked, and then I felt the urge to share.

Learn from the best

I highly recommended reading: The Coding Dojo Handbook by Emily Bache. I think it jumpstarted my journey. It gave me

  • a better idea of the nature of the drill,
  • the structures of it,
  • the pitfalls to watch for,
  • many ingredients to alter the flavors,
  • and even katas to start with.

You can read an endless list of, sometimes contradictory, articles on the internet about coding dojos and TDD. But why would you waste time searching and sorting information when you can have all the needed to start in one book selling for a couple of bucks ? I have no affiliation with the author but I think she did a great work with her book and she deserves to be mentionned and to sell many copies of it.

Prepare

Maybe one day you will be so used to the drill, you will just come empty handed, choose a problem the hour before the session, get in, type in some commands and start coding and/or facilitating. Before you (and I) reach this level of mastery...

The best is to prepare thoroughly:

  • Make a git repository with all the tooling necessary installed and configured. A first test is a must have.
  • Choose a problem and explain it in a README file.
  • Decide on the goal for the session (introduce TDD, illustrate refactoring or patterns, demo a new tool...).
  • Choose the rules and constraints for the upcoming session.
  • Match the problem and the rules, ie overall difficulty, with the audience
  • Best is to solve the problem before, one or several times. Doing so you will spot the missing bits in your preparation, because if you ask yourself questions, your audience would probably too.
  • If you want participants to push their solutions to your repository, invite them a couple of days before the event and have them ready to push before the dojo starts.

Enphasize on the basics

When you learn a new thing, it is best to start small and stick to the basics. Basics are the fundations of a pratice (like scales with music, footwork with boxing...), a place to come back many times on the path to mastery (martial arts enthusiast and former krav maga instructor here).

The basics your group should master as soon as possible are :

  • TDD rules and flow : baby steps, red-green-refactor. Always starting with a failing test can be counterintuitive for some and hard to grasp.
  • Commit for every iteration, as small as it can be. This insure you can rollback without loss if you get stuck in the next iteration.
  • Driver-navigator roles segregation : one should never try to take the work from the other, neither way. The facilitator should watch for this and the participants must follow a strict discipline for the drill to be smooth.

Start small

Choose very simple katas for the first two to three sessions. You need to get used to facilitating such events, and your audience needs to get used to TDD.

Katas I would recommend :

  • Hello World : with bonus requirements, as an introduction to TDD.
  • Fizz Buzz : remains very simple, making room for some added constraints like ping-ping pair programming.
  • Tennis : a tad more difficult, but not so much. Here you can decide on new constraints, depending on your group's latest progress.

Constraints and styles, by order of difficulty :

  • Driver-navigator, limited to 3 to 5min. Start high and decrease if you see the audience is not engaged enough.
  • Ping-pong pair programming.
  • Test-commit-revert: be carefull with this one, it is hard and sometimes frustrating for some. Try it on a problem the group already solved and enjoyed. It will push them to find small steps than the first time.

There are many other constraints you can find in The Coding Dojo Handbook or imagine yourself. But beware, do not try too much too soon. Developers too have egos and emotions, if you make them fail too hard, it will impair their enjoyment. Remember these sessions shoud be intense but FUN.

Iterate but do not deviate

Session after session, you will build a ideal of the practice and it is a good thing to envision a destination I guess. In the meantime, if you are successful with your first sessions, you will see enthusiasm from your participants. So much that sometimes they will push many suggestions for the next sessions.

  • Take note of all of them, hear what people say, write it down, find out what can help you to improve. This feedback is gold, do not waste it.
  • Also learn when to say "it is not how I view things, why not you try it that way?". With this stance, you stay focused on the basics at first, and on where you planned on going, but you also onboard someone else on the process. The more events we organize, the better I guess. So accept different opinions, encourage people to give it a try, stay kind and helping, favor discussion, offer help. I see no competition in organizing such events, on the contrary : I personnaly aim at spreading the fire.

Conclusion

Personal opinions

  • A coding dojo can illustrate many things, but TDD is the basic. Before trying to innovate, I would recommend to stick to the basics. I tried myself to innovate, this is a lot of work and uncertainty about the result. In the beginning, I want to add create momentum. Enjoying ourselves is the best way to create momentum in my opinion.
  • During a dojo, participants should be under some kind of pressure. Time, complexity and constraints should aim at pushing them into the zone (reach a flow state even). Check regularly for their engagement and adapt quickly, raising or lowering the pressure with constraints.
  • If you disagree with some of all this, then find your own style and share. Diversity will be beneficial in sorting out what works and what do not.

Overall

This is only the beginning of the journey for me. I plan on bringing this to my next company and to share with as may people as possible. Next I plan on publishing some cheat sheets for the facilitator, about what is the ping-pong flow, the test-commit-revert, or some experiments of my own. Stay tuned!