The Coding Dojo - a Forum for Improving your Coding Skills

Emily Bache, @emilybache
Bache Consulting, http://coding-is-like-cooking.info

The Coding Dojo is a training session where professional programmers practice and improve their skills, and work with Test Driven Development (TDD) in particular. You do Code Kata exercises in a group, play collaborative games, and reflect on not only the code you end up with, but the process you used to create it. I see it as a good way for a group of programmers to sustainably change the way they work, and introduce more effective coding practices.

On Coding Skills

As a professional programmer, at a basic level, you of course have to know the programming language, libraries and frameworks for the system you’re building. Beyond that, there are actually many other general programming skills that make a big difference to how effective you are. From basic keyboard skills, being able to navigate your editor and version control software, to more complex skills like object-oriented design.

These days, an important skill is Test-Driven Development. Many teams assume you will create automated unit tests for all the code you write. In my experience, many developers struggle to write good tests, and of course, simply writing unit tests is not the same as doing TDD.

TDD is a disciplined way of working that puts the creation of automated unit tests at the heart of a minute-by-minute development cycle. New functionality is preceded by a failing test that demonstrates and defines the next increment of production code. You are always only a few minutes away from passing tests and working code. When it’s working well, you get this wonderful feeling of productivity and freedom. It’s really not the same as just writing unit tests while you develop!

There are important secondary skills that come with learning TDD; not just skill in designing test cases, but also refactoring, incremental development, and object-oriented design principles. That last point might not be obvious - but if you do TDD, you are forced to ensure your design is testable before you implement it. A testable design will likely follow principles of good Object-Oriented Design such as the Dependency Inversion Principle and the Single Responsibility Principle. [1]

So how do you learn a skill like TDD? The classic response to a skills gap is to send developers on a training course. Something like two to five days in classroom-based instruction. The thing is, what I usually see is developers coming back from these courses going back into their old codebase, and coding just the same old way as before. TDD doesn’t seem to stick.

Learning TDD is like…

I think TDD doesn’t easily become a habit, because learning it is a bit like an experience I had when I first learnt downhill skiing. Allow me to tell you the story.

I had previously done quite a bit of cross-country skiing, but on this particular occasion, I was at a downhill skiing resort with some friends, so decided to give it a try. I hired some suitable equipment, and successfully got myself up to the top of a beginner piste. I looked at the slope and it didn’t seem too precipitous, so I gently changed my balance and did exactly as I would have on the cross-country skis - put them in a "V" in front of me, and went gliding gracefully all the way down to the bottom, to the applause of my friends. Great start!

Unfortunately, it wasn’t to last. I realised that this technique with the "V" shaped skis, (also called a snow-plow), doesn’t scale. It only works on really quite gentle slopes - the kinds you get when cross-country skiing. To get to the really exciting downhill slopes and exhilarating wind-in-hair high mountain experiences, (yay!) I needed to learn another technique. To ski at speed when it’s steep, you have to keep the skis parallel and swing your whole body from side to side - the "V" shape just doesn’t work.

So I went up to the top of the beginner slope again, and this time, determinedly put the skis parallel to one another. I think I got about 2 meters before I went face-first in the snow! It must have taken me a good twenty minutes to get down that slope, falling over every few meters as I lost my balance or got my skis tangled up. A slope which posed absolutely no difficulty when I could use a technique I knew, became almost impossible when using the new technique!

Of course, with some perseverance, practice, bruises, and a little help from my friends, I got there eventually. It was always tempting to go back to the "V" shaped skis, but gradually the new technique started to stick. Before long I could ski down a steep-ish slope that would have been pretty challenging on my cross-country skis.

I think this kind of learning experience should be familiar to developers who have tried to do TDD. You already know techniques that will let you write the code without any particular difficulty, and it takes effort and encouragement to use TDD instead. If you do persevere, as with skiing, there is a period when you go more slowly than before. Of course, the biggest problem is often that your production codebase is nothing like a beginner slope!

Effective ways to learn TDD

I think a much more effective method to learn TDD than a two-day training course, is to use mentoring and pair programming. A more senior developer who is already familiar with TDD, spends all their time pairing, reviewing code, and coaching developers on-the-job. This is often backed up with intermittent classroom-like training - from time to time you call a meeting and go through the theory of a relevant topic. This has the added advantage that you get real work done on your system at the same time. The main problem with it seems to be a lack of senior developers who are both available and good at teaching and coaching. It can be prohibitively expensive to hire in someone external to do it.

For many developers, they have to learn TDD without much outside help. You get teams with one or two people who are enthusiastic about it, but they have little skill or experience in the technique. I was in this position myself some years ago - I wanted to do TDD, but none of the rest of my team really knew what it was even. It was only later, when I discovered the Coding Dojo, that I realised I’d found a good mechanism to effect this kind of change from within a team.

What is the Coding Dojo?

Coders have always met for hackathons and code nights and user group meetings and suchlike; the Coding Dojo is in some ways similar. You get a group of programmers together, write code and talk about it. There are no managers or deadlines or users, it can be great fun, and very geeky.

The idea with a Coding Dojo is that you get together with the same group on a regular basis - for example a couple of hours every two weeks. It doesn’t have to be a group of colleagues, (although that has advantages for your daily work together), I’ve also done dojos with acquaintances at my local Python user group, and with strangers I’d just met at a conference. You work on simple exercises (see the box below ‘Code Kata - Leap Years’), and practice general programming skills. In particular, you’ll practice TDD.

Martial Arts and Coding

Dave Thomas (one of the authors of ‘The Pragmatic Programmer’), wrote a blog post [2] where he encourages programmers to practice using Code Katas, just like martial arts practitioners use physical Kata exercises. If you’re learning Karate, you’ll practice the same ‘Kata’ over and over. It’s a sequence of moves that you use to train your body and muscle-memory. Later, when sparring, these moves come easily and can be worked into a more spontaneous sequence. In the same way, programmers can practice Code Katas to learn techniques they can later use in production code.

Code Kata: Leap Years

Write a function that returns true or false depending on whether its input integer is a leap year or not. A leap year is divisible by 4, but is not otherwise divisible by 100, unless it is also divisible by 400.

Examples:
    1996  --> true
    2001 --> false
    2000  --> true
    1900  --> false

This Leap Years exercise is a straightforward Code Kata that I often use with complete TDD beginners. To solve it, you just write a function that takes an integer argument and returns a boolean. It’s not hard to do, the problem is set up so you can ignore all the complexities of real dates and Gregorian calendars and suchlike. You can just focus on using TDD to develop the implementation - in fact the four examples translate very easily into test cases. At least after the first time you solve it, you should find it pretty easy to test drive this function, incrementally building up the solution and refactoring when necessary.

Of course, production code isn’t usually this easy, you’ll probably want to practice on other Code Katas before you’re fully fluent with the technique! If you’ve mastered this Kata though, the next time you realise you need a function that returns a boolean in your production code, you should have a better idea of how to test drive it.

The thing is, doing Code Katas by yourself can actually get quite boring, and it’s hard to keep motivated. It was a French programmer - Laurent Bossavit - who suggested extending the martial arts analogy [3]. For example, if you’re learning Karate, you go to your local Dojo every week and practice with a group. Laurent suggested you could do something similar with programming skills. He and Emmanuel Gaillot set up the first ever Coding Dojo, in Paris.

That was in 2005, and later that year I was lucky enough to meet them and experience the first Coding Dojo outside of France [4]. It was great fun, and I was not the only one there who realised how useful it could be as a forum for professional programmers to improve their general coding skills, and TDD in particular. Since then many hundreds of Coding Dojo meetings have taken place around the world.

What happens at a Coding Dojo?

I think there are a few distinguishing features of a Coding Dojo that set it apart from any other kind of meeting where programmers get together and write code together:

1. Hold an introduction and retrospective
2. Write tests as well as code
3. Show your working
4. Have moderation or facilitation

The introduction helps everyone to focus, and gives newcomers a chance to ask questions. The retrospective is useful to improve future meetings, but also to get people to reflect on what they have learnt, so they are more likely to remember it. You write tests in the Coding Dojo partly because one aim is to learn TDD, but it’s also a great way to get concrete feedback in a short space of time. Does the code work? Run the tests!

Point 3 is particularly important - this is not meant to be a code review, where you admire each other’s fine designs and criticise people’s curly-bracket placement habits. (Been there, done that!) You’re trying to learn the moves of good coding - what does it actually take to go from an empty editor to a working piece of code? How do you choose the order of tests? What kinds of feedback do you pay attention to?

The last point is about having leadership, (see also the section below "Mastery"), but not necessarily a mentor or teacher. It more refers to someone who will keep discussions on track, promote collaboration, and create opportunities for learning. Someone who will ask good questions, or suggest a change of activity when the group is getting hung up on something irrelevant.

Practice

"Practice makes perfect" so the saying goes, and one of the reasons for doing exercises in the Coding Dojo is in order to practice new skills. What people don’t always realise is that there are two different kinds of practice [5]. The first is the one you’re probably familiar with: Incidental Practice. This is where you repeatedly do something you can already basically do, and improving gradually at it. The second is Deliberate Practice. This is where you take a decision to do something that you can’t already comfortably do, and consciously repeat the experience in order to learn it. You may also break the skill or activity down into components that you practice separately.

For example, a musician might learn a piece of music by playing it repeatedly, gradually gaining fluency. That’s incidental practice. The same musicians could also learn a piece that is too difficult for them, that they can’t yet play comfortably enough to repeat like that. They might start by just playing scales, or short excerpts from the piece at a slow speed, before carefully and thoughtfully attempting the whole. That’s deliberate practice.

The hallmark of deliberate practice, is that you feel uncomfortable while you’re doing it. You’re stretching yourself beyond your current ability. The trick is to choose an activity that stretches you just the right amount - not too much - just enough that you will soon become comfortable with the new skill, and transition to doing incremental practice.

In the Coding Dojo, you may feel that discomfort when you start doing TDD on an unfamiliar Code Kata. If you’re going to persevere with this deliberate practice, and learn how to do TDD on this new kind of problem, you’ll need to feel safe, and you’ll need to feel motivated. The atmosphere, the camaraderie, the facilitation, the choice of exercise… all need to align to create a good learning environment. Safety partly comes from knowing you’re not working on production code - that there is no customer. Motivation often comes from your peers in the group. You are surrounded by encouraging people who give you useful feedback.

When I introduce the Coding Dojo to a group, I’ll usually emphasise this point. Everyone should be helpful, and contribute to a safe environment. It’s a prerequisite for learning.

Collaborative Games

You have probably played competitive games like chess, or monopoly, or football, and they can be great fun. In the Coding Dojo we also like to play games, but I try to avoid competitive ones. I say this because a competitive environment can damage the feeling of safety needed for people to try new things. Basically I find collaborative games seem to promote a better learning environment.

What I mean by a Collaborative Game is one where the players try to defeat the game itself, rather than each other. You may have played games like ‘solitaire’, or ‘minesweeper’ where you play alone, but your aim is to defeat the game. A collaborative game is like that, except you’re not working alone. There are rules, activities, goals, and fun to be had, without anyone becoming the ‘winner’ or ‘loser’.

There are various kinds of games you can play in a Coding Dojo. One of my favourites is called ‘Randori’. The idea is that you will solve a code kata as a group, with everyone having a hand in the solution. The way I usually do it is to seat about 10 programmers around a conference table. You set up a development laptop in front of one person, with the screen projected where everyone can see it. The person by the laptop starts working on the agreed Code Kata, listening to suggestions and discussion from the group. About every 5 or 7 minutes, a timer rings, and everyone stands up and moves one seat to the left. When you find yourself sitting by the keyboard, the challenge is to understand what’s been done already, write some useful code, and not leave it in a disastrous state for the next person! It can also be quite challenging for the moderator to keep the discussions on track, and ensure the person typing is not overwhelmed - with ten programmers in the room there could easily be twelve suggestions for what code and tests to write next!

This is a fun activity that should lead to good discussions afterwards in the retrospective. I’d expect to talk about things like how to work incrementally, what is readable code, choice of test cases… issues we may have met in our ordinary work, that appear in a more extreme way in the game. Other games you can play in the Coding Dojo may highlight other issues. You’re trying to get people to think about how they code, and how they collaborate, as well as critique the design they end up with.

Tools for the Dojo

One of the things I like to do in a Coding Dojo is to use a Test Run Logging tool, such as Cyber-Dojo [6]. While you're in the middle of doing TDD, it can be hard to pay attention to how well your TDD session is going overall, so it can help to have a tool monitor it for you. Every time you execute the tests, it can record how long since the last test run, and whether they passed or not. After you've finished working on a code kata, you can go back and review the data.

The log should show you your TDD cycles - a repeating pattern of failing tests followed by passing tests followed by several more passing test runs: cycles of Red - Green - Refactor. These cycles will ideally be frequent and clear in the log. A large gap between test runs could be a sign you’re not working in small enough increments. A long string of failing tests could be a sign you’ve struggled for too long trying to recover from a mistake rather than just reverting the code and starting the TDD cycle again.

Figure 1: A test run log from a pair of TDD beginners. Red means failing tests, amber is compiler or syntax error, and green is passing tests. Time moves forward on the x axis.

I think figure 1 gives some useful feedback that the pair might not have discovered otherwise. The TDD cycles are rather erratic, sometimes with lots of failing test runs in a row. Figure 2 shows a more experienced pair. You can easily see they run the tests more often, and the TDD cycles are much clearer.

Figure 2: A test run log from a more experienced pair of programmers

Mastery

This is possibly where the analogy with martial arts starts to break down. If you go to a Karate Dojo, you’ll probably meet a very experienced, skilled practitioner who is called the ‘Sensei’ or ‘Master’. This person will lead by example, teach, and critique. In a Coding Dojo, I don’t think you’ll necessarily have such a person, or even find it necessary. Coding is a wide discipline with many branches that moves forward very quickly. You can be very skilled in one area without knowing anything about another. A vanishingly small number of programmers can claim the title ‘Master’. In fact, I don’t think it really helps to put someone in your dojo on a pedestal like that.

One of the things that came out of the original Paris dojo is the Dojo Principles [7], and I particularly like what it says about mastery. To summarise:

• If it seems hard, find someone who can explain it.
• If it seems easy, explain to those who find it hard.

No-one has mastery in all areas; everyone should come to the Dojo expecting to both teach and learn.

A Challenge

I hope if you’ve read this far, that perhaps you’ve become intrigued by the idea of the Coding Dojo, and would like to try it. There could already be a Coding Dojo in your area, ask around. If there’s not, you could always start one! There are materials freely available online that can help you, for example Cyber-Dojo that I mentioned earlier [6]. I’ve also written a book [8] and a video training course [9]. In any case, I hope you’ll think twice before simply going on a two-day TDD classroom-based training course!

References

1. https://github.com/lucaminudel/TDDwithMockObjectsAndDesignPrinciples/blob/master/Paper/mockobjects_emergingproperties.pdf - a paper by Luca Minudel
2. http://codekata.pragprog.com
3. http://bossavit.com/dojo/archives/2005_02.html
4. "The Coder's Dojo - A Different Way to Teach and Learn Programming" workshop presented at XP2005 conference by Laurent Bossavit and Emmanuel Gaillot
5. http://en.wikipedia.org/wiki/Deliberate_practice#Deliberate_practice
6. http://cyber-dojo.com/
7. http://codingdojo.org/cgi-bin/index.pl?CodingDojoPrinciples
8. http://pragprog.com/book/ebdojo/the-coding-dojo-handbook
9. http://pluralsight.com/training/Courses/Description/the-coding-dojo

---

More articles on programmer training and Test-Driven Development (TDD)

Software Testing Dojos

Improving Application Quality Using Test-Driven Development (TDD)

Test Driven Development (TDD) Traps

---

Click here to view the complete list of archived articles

This article was originally published in the Fall 2014 issue of Methods & Tools