What Is a Coding Dojo?
So in case you don't know what a Coding Dojo is, here is a short introduction.
I view it basically as a coding gym or training camp where you practice coding in and as a team. "Dojo" is Japanese and means "...a hall or space for immersive learning...". Within that Dojo, you work on coding "Katas" meaning "a detailed choreographed pattern of movements made to be practiced alone, and also within groups and in unison when training".
How Does it Work?
As always, what works for you is fine. This how we do it and have good results with it.
Preparation
- Pick a Kata
- e.g. from here
- Don't use prod code! (see "No Prod Code" rule below)
- Usually, you don't want to build a full-fledged application with UI, server etc.
- Prepare the development environment in advance
- git repository is set up
- Project is open in IDE
- Test are running (as in "no errors" although you have none)
- Choose a room that can comfortably carry your team and has a large display or projector
- Bring one computer, one mouse, one keyboard (or more keyboards, if you need other layouts)
- Block 1,5 hours of time
- Repeat that every iteration (e.g. 2-3 weeks)
- Choose a moderator that will not code (e.g. Scrum Master or any random team member)
- Choose a programming language if multiple options exist (you can e.g. shuffle through every Kata)
Action
- At the beginning of each new Kata, first discuss a basic approach (top down, bottom up etc). Max 10 minutes.
- First random member gets keyboard and mouse for a maximum of 5 minutes (active member)
- The moderator will check the time box
- The active member will explain all of her/his thoughts while approaching the problem and starts writing a test and then implementation in a TDD fashion.
- The active member may ask for help when stuck.
- The rest of the team must not interrupt or help even if they see a bug, typo or whatever. The moderator must take care of that. Apparent bugs can be fixed in the next slot.
- When the time is up, the keyboard is handed over to the next member in a circle.
- The moderator should check that the code is checked into git as often as possible with sensible message (yes, also that needs practice!)
- When the moderator feels that the team is stuck, another 10 minutes team discussion slot is possible.
Important Constraints
It's Not About Puzzles
One important aspect is that it's not about writing algorithms or solving puzzles. It's not even about finishing the Kata!
It's about what happens in between.
It's about team building. It's about the knowledge exchange. It's about the discussions that might happen. It's about learning how people approach problems differently. It's about giving the time to think.
The "No Prod Code" Rule
Someone (maybe managers, maybe even team members) will come up with the idea to just work on a problem in your prod code. But the Coding Dojo must remain a safe space. This is why Katas are used. When the team would work on prod code, you will work under pressure. You will make compromises. You will skip tests.
Why You Should Probably Already Do It
So, now let's talk about why you should probably do it.
Team Norming
The first and most important reason is: To build a sustainable and well-performing team. Every team goes through four phases: Forming, Storming, Norming, Performing.
You want to be the "Performing" phase, obviously. However, after a new team has been formed or after a new member joins, you will very likely come the "Storming" phase again.
Storming happens, when a team is not normed. E.g. when some members writes tests, some not. Some writes code comments, some not. Some like tabs, the others spaces. You get the idea. When there is no explicit agreement, you will get in troubles sooner or later. So even though you need a common understanding in a team upfront, practicing that in a team during Coding Dojo is really important.
Norming is not always easy, it's about finding the sweet spot between individual talent and team work that should lead to less discussions and arguments.
Team Responsibility
A special type of "norming" is team responsibility. It means that all members feel responsible for all of the team code. There should not be something like "Hey, you introduced that bug the customer reported, you need to fix it!".
Because of the fact that the whole team works on the same code, team responsibility is trained and will benefit the prod code as well.
Craftsmanship
Coding Dojos helps to learn coding as a craft. It's important to repeatedly train your skills.
When you as a team decide to follow Clean Code rules and Test Driven Design (and you should) or you want to start learning it and are afraid or unsure to practice it on prod code, Code Dojos will help.
Knowledge Sharing
During a Coding Dojo, every team member - no matter how much experience - will learn something new. Apart from learning general coding styles, team members will learn new design patterns, refactorings, IDE short cuts and tools.
We used it to learn TypeScripts. We had only Java backend developers that wanted to learn TypeScript to work on front-end code as well. So we did a Kata in TypeScript.
Social Skills
Because of the fact that the team needs to solve a problem together and each non-active member needs to take him/herself back a bit, Coding Dojos train social skills in team communication, openness and self-control.
Most developers know situations where other team members do have their own idea how to develop software which conflicts with team decisions. Coding Dojos help to make that behavior transparent and work on it. It will slow down very confident developers and give more room for inexperienced ones.
Get a Glimpse of Mob Programming
Actually, mob programming is currently hyped and a Coding Dojo works similar (but not exactly the same): You work as a team (mob) on one code base with time boxing.
The difference is, that the "rest of the mob" is not driving the active member.
When To Stop?
Now, here comes my confession: My team doesn't do it at the moment. Why not? We have reached Norming and Performing phases. Each team member writes code that the others value and would probably have written in a similar way. We do most coding in pair and even mob sometimes. There are very few discussions or disputes and we feel a strong team responsibility. So we as a team decided to stop it but we will start again no later than when a new member joins.
So, while you can obviously continue as long as you like, you can stop if the team has formed.
