In martial arts, a dojo is not just a training hall. It is a philosophy. A place where you practise the fundamentals until they become second nature. Where the emphasis is not on learning new techniques every week, but on mastering the ones you already know.
Software development could learn a lot from this approach.
The Problem with Learning on the Job
Most developers learn primarily through their work. They pick up new frameworks when a project demands it. They learn about testing when a bug slips through. They discover the importance of clean architecture when a codebase becomes impossible to maintain.
This is learning through consequence, and while it works eventually, it is slow, painful, and expensive. You are essentially using production systems as your training ground.
Imagine a surgeon who only practised during real operations. Or a pilot who only trained during commercial flights. The idea sounds absurd, yet this is exactly how most software teams operate.
What Deliberate Practice Means
Deliberate practice is a concept popularised by psychologist Anders Ericsson. It has three key characteristics:
It is focused. You work on a specific skill, not everything at once. Today you practise writing clean functions. Tomorrow you practise refactoring legacy code. The day after, you work on test design.
It involves feedback. You need someone or something to tell you what you are doing well and what needs improvement. In a dojo, that is your instructor. In software, it can be a mentor, a pair programming partner, or a well designed code review process.
It pushes you beyond your comfort zone. If the exercise is easy, you are not learning. Deliberate practice should feel challenging. That discomfort is where growth happens.
How the Dojo Model Works
Our workshops are built around these principles. Each session has a clear skill focus. Participants write code, get immediate feedback, and iterate. There are no slides. There is no sitting and listening for hours.
A typical dojo session looks like this:
- Introduction (10 minutes): The facilitator explains the concept and the exercise.
- First attempt (30 minutes): Participants work through the problem, usually in pairs.
- Review (15 minutes): The group discusses approaches, trade offs, and common mistakes.
- Second attempt (30 minutes): Armed with new understanding, participants try again.
- Reflection (15 minutes): What did you learn? What would you do differently?
The magic is in the second attempt. By the time you come back to the problem, you have heard other perspectives, identified your own blind spots, and formed a clearer mental model. The improvement between the first and second attempt is often dramatic.
Repetition Is Not Boring
One objection we hear regularly is "why would I solve the same problem twice?" This reveals a misunderstanding about what repetition does for skill development.
A musician does not play a piece once and move on. They play it hundreds of times, each time refining their technique, their timing, their expression. The goal is not to get through the piece. The goal is to internalise the patterns so deeply that they become automatic.
The same applies to software. When you practise test driven development on a simple problem, you are not learning that specific problem. You are building the neural pathways for a way of thinking. You are training your instincts. So that when you face a complex, high pressure situation in production code, the approach comes naturally.
Building a Practice Culture
The most powerful thing about the dojo model is not what happens during the session. It is what happens afterwards. Teams that embrace deliberate practice start to see their daily work differently.
Code reviews become learning opportunities, not gatekeeping exercises. Pair programming becomes a natural way to share knowledge, not an awkward obligation. Retrospectives become genuine reflection, not a ritual to endure.
This cultural shift is what separates teams that grow from teams that simply accumulate experience. Experience without reflection is just repetition. Experience with deliberate reflection is how you build genuine expertise.
Starting Small
You do not need a formal programme to start practising deliberately. Here are three things any team can do this week:
Set aside one hour. Pick a problem from an online kata catalogue. Work through it as a team, focusing on clean code rather than speed.
Review your own code from six months ago. What would you do differently? What patterns do you see now that you missed then?
Pair on something unfamiliar. Find the area of your codebase that nobody understands and explore it together. Ask questions. Draw diagrams. Build understanding.
The dojo is not a place. It is a mindset. And it starts with the decision to treat your craft seriously enough to practise it.
