As part of the “software consultant” gig, I often get involved with mentoring developers and teams. Mentoring developers one on one works pretty well, but after a point, it’s quite hard to scale the face time you can give to teams or departments of 50-60 people.

The truth is, that people learn by doing, and people learn from each other – so one of the most important things to do in your technology department is bake that culture of learning and development into the day-to-day. I’ve had good success using code dojos as a crutch to introduce pair programming and learning into departments in a couple of different companies.

So what’s a code dojo?

A code dojo is session where you perform "coding katas" to practice, improve and learn. The concept comes from Japanese martial arts, and I'm going to liberally borrow from the wikipedia page on the subject.

Kata, a Japanese word, are the detailed choreographed patterns of movements practised either solo or in pairs. The term form is used for the corresponding concept in non-Japanese martial arts in general.

Kata are used in many traditional Japanese arts such as theatre forms like kabuki and schools of tea ceremony (chado), but are most commonly known for the presence in the martial arts. Kata are used by most Japanese and Okinawan martial arts, such as aikido, judo, kendo and karate.

The basic goal of kata is to preserve and transmit proven techniques and to practice self-defence. By practicing in a repetitive manner the learner develops the ability to execute those techniques and movements in a natural, reflex-like manner. Systematic practice does not mean permanently rigid. The goal is to internalize the movements and techniques of a kata so they can be executed and adapted under different circumstances, without thought or hesitation. A novice’s actions will look uneven and difficult, while a master’s appear simple and smooth.

The way that we interpret katas in software development is to practice coding by solving synthetic or interesting problems that are similar to a variety of real world problems. Generally, katas are performed as "pairs", with two people sharing a single computer, alternating in participation in the task. This is called pair programming, and it's a great way for people to learn from one another – it’s a common extreme programming / agile practice.

Pair programming is an agile software development technique in which two programmers work together at one workstation.

One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in.

The two programmers switch roles frequently.

Why do we do katas?

We learn archetypal solutions to common types of problems - commonly, programming tasks of similar shapes share similar solutions - so practising building quick solutions to these problems helps us in our practical work.

We learn alternative solutions to things we thought we knew well - one of the joys of a kata is the inverse of the first point - because the kata is practice, and explicitly not real code, the risk of failure is removed and we can learn and experiment with alternate approaches to categories of problems.

We learn how our peers approach problems - the way individuals think about solving problems is drastically different, and the best way to improve your skills is to learn from other talented people. A code dojo gives you the opportunity to pair program with someone who you might not normally work with, or who has a distinctly different skill-set than you do.

We get to work on some fun, interesting problems - over multiple sessions, you'll get exposed to different categories of problems, that should be approached in varying ways - it's one of the easiest ways to expose yourself to new kinds of development.

It's safe to try out new languages - katas are one of the best ways of learning new languages - they're a safe, failure-free environment to play and learn in.

The first kata

I’m working with a new client at the moment, and this week we ran the first code dojo.

The first kata involved building a "zero player videogame" in an hour by implementing Conway's Game of Life. It's a really fun first dojo, because it's out of the comfort zone of the kinds of things most "developers who work on business software" normally get a chance to program.

Some of this is paraphrased from the excellent wikipedia article and I was inspired to pick this particular kata because of a blog post I recently read by Jeremy Bytes about implementing the game in TDD, highlighting the natural fit for a kata.

The Game of Life is a cellular automaton devised by the mathematician John Horton Conway in 1970.

The "game" is a zero-player game, meaning that its evolution is determined by its initial state, requiring no further input. One interacts with the Game of Life by creating an initial configuration and observing how it evolves or, for advanced players, by creating patterns with particular properties. The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead.

Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, cells evaluate their state and transition between being alive and dead depending on their neighbours.

The initial pattern constitutes the seed of the system. The first generation is created by a set of rules simultaneously to every cell in the seed. Births and deaths occur simultaneously, and the discrete moment at which this happens is called a tick.

We ping-pong-paired (one person writes a test, the other makes it pass and writes the next) six different solutions to the Game of life, in the room, in just over an hour.

The full outline of the first code kata is available on my github account, if you want to have a go yourself along with my quick (and sub-optimal!) implementation in C# here. If you're going to have a go, I'd suggest you don't look at any solutions first.

Here's one we made earlier:

Consider running some code dojos

The great thing about code dojos is they’re easy to get off the ground.

You just need a few people, some snacks, and a problem. If you want to get started, there’s lots of ideas on http://rubyquiz.com/ that you can base katas from – though it might take a little bit of prep work on behalf of the organiser to reformat some of their questions.

Over the next couple of weeks I’m going to try dig up some of the katas I ran with my last client and make them available – mostly reformats of old rubyquiz quizs – but with structured user stories and examples.

Code dojos and katas help you prevent premature specialisation, and they're good fun.