Coding dojos in practice
A safe space for learning in software development
“I can’t imagine a better place to learn than a coding dojo.” A colleague said this after our third dojo session together. We are both agile software developers and had just spent five hours working on the “Mars Rover Kata” alongside six other developers. Two additional rules made the exercise even more exciting: we were not allowed to use a mouse or an “if-else” statement.
About once a month, we deliberately step away from our day-to-day project work. We then use the time to try out new programming languages or frameworks, practise development methods, or work specifically on a technical problem. This format has proved so successful for us that we now also facilitate coding dojos in companies – with consistently positive feedback.
What is a coding dojo?
The term ‘dojo’ (Japanese: dōjō, 道場) originates from martial arts and means ‘place of the way’ – essentially: a space for learning. In martial arts, techniques are practised and internalised there. A central element of this are so-called katas: stylised sequences of movements used to train specific actions and principles.
This concept can be applied to software development: a coding dojo is a training format for software developers. Crucially, it takes place in a safe space: free from external distractions, without pressure to be productive, and without real-world project responsibilities, participants can try out new practices or technologies together.
In my experience, the ideal group size is between two and eight people. However, the optimal number of participants also depends on the specific topic of the coding dojo. The key is that everyone can actively participate. A coding dojo is a collaborative training session, not an event for spectators. At the end, the participants reflect together on their experiences and discuss the benefits, limitations and potential practical applications of what they have learnt.
Coding katas are clearly defined exercises used to test technologies, methods, tools or practices in the doding dojo. Unlike in martial arts, however, the aim is not to repeat fixed sequences over and over again or to memorise a specific solution. In the coding dojo, the focus is instead on finding solutions creatively. Even if the same kata is worked on several times, both the path to the solution and the result are different each time.
To make a kata even more exciting, additional constraints can be introduced. These so-called constraints specifically increase the level of difficulty, often in deliberately unusual ways. This keeps the training playful yet challenging. At the same time, communication patterns within the team become apparent, which often leads to valuable ‘aha’ moments in everyday working life.
The unique benefits of coding dojos
Coding dojos are deliberately designed to be hands-on. Rather than theoretical training on a topic, the focus is on learning and practising together in a safe space. A spirit of experimentation is actively encouraged, and having fun plays a central role!
This requires mutual respect to create a positive learning atmosphere free from fear. This includes a culture where mistakes are seen as a natural part of the learning process and experimentation is actively encouraged.
The constraints offer the opportunity to further tailor a coding dojo to the group’s composition and give the whole experience a special twist. If the participants are experienced or work together in their day-to-day professional lives, this prevents routines from setting in and enables a whole new level of motivation to be unleashed, allowing them to master challenges together.
At the end of the day, you look back and realise that you have gained a fair amount of new experience. Whether it’s with a new technology or a new way of developing software together. Often, both are the case.
Three examples of coding katas
There are many different types of coding katas. They usually present a clearly defined, often deliberately simplified scenario within which developers can practise applying a specific technique, method or approach. A key aspect is engaging with different approaches to solving problems. In day-to-day software development, it is often important to be able to respond flexibly to challenges. This will be significantly easier for those who have regularly tried out different approaches to problem-solving in coding dojos.
Example: Mars Rover Kata
This kata comes in many variations. Here is a simple one:
Task:
You are part of a team exploring Mars. Remote-controlled vehicles – the rovers – are to be sent to the surface. You are developing an API that translates commands sent from Earth into instructions that the rover understands and executes.
Requirements:
- Given are the rover’s starting point (x, y), its orientation (N, S, E, W) and a list of obstacles (x, y) located on the map.
- Simplified assumption: The rover has landed on a square plateau divided into 100×100 squares.
- The rover receives a string of commands.
- ‘F’: move forwards; ‘L’: turn left; ‘R’: turn right.
- After processing the string, the final position and orientation must be output.
- Obstacle detection takes place before every movement to a new square. If a specific sequence of commands encounters an obstacle, the rover moves to the last possible point, aborts the sequence and reports the obstacle.
- The rover must not fall off the plateau: edges are treated as obstacles.
Depending on the objective of the dojo, you can simplify or extend the task. For example, you can omit obstacles or the boundaries of the plateau and work with an infinitely large world. If you wish to make the task more complex, you could model a spherical world, in which a correct circumnavigation must be implemented. Another variation involves using a polar coordinate system instead of a Cartesian grid.
Example: Refactoring Kata
In a refactoring kata – a well-known example is Emily Bache’s Gilded Rose Refactoring Kata [1] – participants are given an existing codebase and a list of requirements. Their task is to implement a specific behaviour whilst simultaneously improving software quality.
The aim is not simply to find any solution as quickly as possible. Instead, they compare different approaches and evaluate their quality.
- Which structure is easier to maintain?
- Which solution is clearer?
- Which is more testable?
Participants try out different approaches and then reflect together on the results.
An important lesson here: in software development, there are often several possible solutions for many tasks. However, they are not all equally good. The training sharpens your eye for code quality and for structural decisions in design.
Agility Katas
Agility katas – such as the CSV Viewer Kata from the CCD School [2] – are more closely based on the principle of repeated iterations, which is also familiar from martial arts.
In this process, you work through a task in several iterations. With each round, the requirements change or become more complex. The aim is to practise dealing with evolving requirements.
In this way, typical challenges from real-world projects can be simulated. You practise dealing with changing requirements and adapting your solution step by step.
Collaboration in a coding dojo
As well as technical topics, coding dojos also provide a focused opportunity to practise agile software development techniques that often get overlooked in day-to-day work. These include, for example, pair programming and ensemble programming.
Away from the daily grind of projects, but with a clear task at hand, you can try out these forms of collaboration in practice. You experience first-hand what working together feels like and what benefits it can bring, whether on a shared computer or remotely via a split screen. At the same time, the limitations of these practices also become apparent.
In pair programming, often simply referred to as pairing, two software developers work together on a single computer. One person takes on the role of the driver. The driver operates the computer and writes the code. The second person is the navigator. The navigator maintains an overview, thinks about the next steps and points out possible improvements or outstanding issues. This allows the driver to concentrate fully on writing the code and working with the development environment. As a rule, the driver and navigator swap roles at regular intervals.
In ensemble programming, three or more people work simultaneously on the same task at a single computer. The code is created collaboratively through the different perspectives, experiences and knowledge of all those involved.
The term has established itself as an alternative to mob programming, as it places greater emphasis on the cooperative and appreciative nature of this working method. The basic process is similar to pair programming, but is applied to a larger team. Here too, there is usually a driver and a navigator, whose roles are swapped regularly. Additional roles can also be defined. For example, there is often a facilitator. This person monitors the team dynamics, mediates in the event of disagreements and ensures that respect, curiosity and constructive dialogue are maintained.
Learning more through constraints
Constraints bring added variety and new perspectives to a coding dojo. These are deliberately imposed limitations that make working on a kata more challenging and add another dimension to the task. Some typical examples are:
Blind Navigator
With the “Blind Navigator” constraint, the navigator is not allowed to see the screen. This forces both roles to communicate with each other particularly precisely and clearly. Misunderstandings quickly become apparent, and many implicit assumptions suddenly have to be voiced. For software teams, this is an extremely effective communication exercise.
No Loops
With this constraint, loops such as for, while or do-while may not be used. This forces you to engage more deeply with alternative approaches such as recursion or higher-order functions. These are functions that take other functions as parameters or return them.
No Conditionals
Here, classic decision-making structures such as if, else, when or switch must not be used. This leads to unconventional solutions. Concepts such as polymorphism or lookup tables are often employed.
No-Mouse
With this constraint, you work entirely without a computer mouse. All actions are performed exclusively via keyboard shortcuts. This helps participants learn to use the shortcuts in their development environment much more effectively.
Hot Potato
With the Hot Potato constraint, the role of the driver changes at short intervals, for example every two minutes. This ensures that many participants get an active turn, and the team stays on the move.
Constraints ensure that tasks are tackled in a playful manner and with plenty of energy. At the same time, they force teams to consciously work differently from how they do in everyday life. This leads to new approaches, breaks established patterns and encourages creative thinking.
Conclusion: Why coding dojos are so effective
Coding dojos create something that is rarely possible in the day-to-day reality of project work: a safe space for learning. Without the pressure to deliver, without immediate project responsibility and without the fear of making mistakes, developers can try out new ideas, experiment together and learn from one another.
It is precisely this combination of hands-on work, playful challenges and shared reflection that makes a coding dojo so valuable. Techniques are not merely understood, but actually experienced. At the same time, working together strengthens communication, trust and the ability to explore different approaches.
Coding dojos are particularly helpful in the following situations, amongst others:
1. Introducing new practices
When teams wish to experiment with TDD, pair programming or new refactoring techniques, the Dojo offers a safe environment to try out these practices and experience their effects first-hand.
2. Breaking habits
Teams that have been working in a similar way for a long time discover alternative ways of thinking and solving problems in the Dojo, without having to immediately change their day-to-day project work.
3. Dealing with legacy code
Techniques such as TDD or structured refactoring can be practised using simplified examples before being applied to complex existing codebases.
4. Promoting communication
Working together on a kata reveals communication patterns and improves collaboration – a skill that is crucial in complex software projects.
5. Expanding your personal toolkit
Those who consciously practise new methods and technologies expand their personal toolkit. This enhances the ability to decide, in real projects and in line with the situation, which solution makes sense.
Ultimately, a codding dojo is far more than just a training session. It is a place where teams learn to develop better software together. The best thing to do is simply give it a try.
Extra bonus
Here are 3 additional questions about coding dojos, answered by Philipp Zug (please click on the “+” button):
Do coding dojos need a trained trainer or facilitator?
Philipp Zug: In principle, anyone can organise and run a coding dojo themselves. However, experience shows that the first few sessions often get off to a bit of a bumpy start if participants lack experience with this format.
A common pitfall arises when colleagues from the same team take part together. In such cases, existing team dynamics and roles often persist. This, however, is problematic for a safe learning environment. Those who are dominant in their day-to-day work or are used to giving orders often take on this role in the Dojo as well. Without a facilitator, this behaviour will usually not change of its own accord.
Another sticking point concerns the agreed working method in the Dojo. New methods often quickly fade into the background and participants fall back into their usual patterns. One example is Test-Driven Development (TDD). Although the dojo is specifically designed to practise TDD, some participants immediately start writing code without first formulating a test. An experienced facilitator can intervene here. Often, simply asking targeted questions is enough for the group to realise for themselves that the next step should actually be a test.
An experienced facilitator can assess such situations well and address them if necessary. In this way, the Dojo remains a learning space where new experiences are actually possible.
During the Dojo, trainers can also provide direct feedback, offer small hints or suggest alternative solutions. It is important to first allow participants the space to experiment. This includes making mistakes or getting stuck at times.
After a while, such situations can be put to good use to introduce new techniques. If, for example, many tests are created that are very similar, this provides an opportunity to discuss parameterised testing. This technique helps to write tests that are more compact and less redundant.
It can therefore be particularly helpful for groups with little experience to have a coding dojo facilitated by one or two facilitators. They provide technical support, ensure a positive learning atmosphere and make sure that the training is a positive experience for everyone involved.
Do coding dojos only work when people are together in person, or can they also be done remotely?
Philipp Zug: Both work. For an in-person Coding Dojo, you’ll need at least one computer in a room that’s as quiet as possible and offers enough space for all participants. It’s also important that the screen can be projected so that everyone can see it clearly.
If you want to try out practices such as mob or pair programming, it can be useful to split into smaller groups spontaneously and work together on a single computer.
This can also be done effectively in a remote Dojo, for example using breakout rooms where small groups work together in parallel.
Which tools are suitable for coding dojos held remotely?
Philipp Zug: Standard collaboration tools are suitable for remote coding dojos. I highly recommend the IntelliJ plugin ‘Code With Me’. [3]
In this setup, the development environment runs locally on one participant’s machine, whilst others can connect to it remotely.
A major advantage is that only one person needs the technical setup, such as an IDE, etc. This minimises the technical setup required for the other participants. There is no need for screen sharing or code handover. This means the initial barrier to entry and the effort required at the start are very low. Experience shows that the technical setup can otherwise quickly become time-consuming and lead to frustration.
Disadvantage: The code is not under version control, all participants must use IntelliJ (which not everyone likes) and the host requires a paid licence.
An alternative is Visual Studio: Live Share. [4]
For screen sharing, code handover and timekeeping, I recommend Mob.sh [5] and Git.
Advantage: Everyone has their own familiar setup with their own IDE. The code is immediately in Git.
Disadvantage: Everyone MUST have their own setup, IDE, etc. available before the dojo can begin.
Notes:
Are you looking for support for your first Coding Dojo? If so, please feel free to contact Philipp Zug. He and his colleagues at Colenet are more than happy to help, not only with facilitation or technical queries, but also by providing the necessary infrastructure if required.
[1] Gilded Rose Refactoring Kata
[2] CSV-Viewer Kata
[3] IntelliJ Plugin Code With Me
[4] Visual Studio: Live Share
[5] Mob.sh
There are various online sources containing useful information about coding katas:
Would you like to discuss coding dojos as an influencer or thought leader? Then please share this post on your social media channels.
On the t2informatik blog, you’ll find more posts from Colenet, including:
Organisations develop by themselves
Stumbling blocks in the introduction of Kanban
User stories – when the harm is greater than the benefit
Philipp Zug
Philipp Zug is an agile software developer and trainer at Colenet GmbH. He supports teams in developing high-quality software using agile methodologies such as Scrum, Kanban and Extreme Programming, placing particular emphasis on software craftsmanship through practices such as test-driven development, clean code and pair programming.
In addition to full-stack development of web and mobile applications using technologies such as Java, Spring Boot, TypeScript, Angular and Android, he supports teams in establishing test strategies, DevOps processes in Google Cloud, and build and test automation.
A key focus of his work is coaching developers in their day-to-day work, for example through on-the-job training and pair programming. He regularly organises and facilitates coding dojos and code retreats to support teams in practical, collaborative learning and experimentation.
In the t2informatik Blog, we publish articles for people in organisations. For these people, we develop and modernise software. Pragmatic. ✔️ Personal. ✔️ Professional. ✔️ Click here to find out more.