Coding Dojos are a way for developers to practise together and improve their skills. I first became aware of them through the sessions run by Tom and Joh at Future Platforms. Since then, I’ve run lunchtime sessions at Crunch and now we’re running them as part of Brighton Java.

What happens at a Coding Dojo

The coding dojo begins with a description of a problem. Developers then take turns pair-programming for five minutes each, with one as the driver (using the  keyboard) and the other as navigator (making suggestions). After five minutes, the navigator takes over as the driver and there is a new navigator. As the pairs work, they narrate what they are doing. The IDE screen is also projected so that everyone in the room can see it clearly.

Seeing other people code is good for picking up the different ways people work. As developers we see a lot of people’s code, but few companies offer a chance to see it being written. By changing the people working on the dojo code, we see how developers respond to existing code.

Coding Dojos typically feature the use of TDD. Test-driven development is one of those things that a lot of companies endorse, but few use properly. Trying to maintain a tight test-code-refactor cycle is much easier with an audience to act as a conscience!

At the end of the session, everyone takes a turn saying what went well, what went badly, and anything they’ve learned.

Why would I want to attend a Coding Dojo?

Whatever your exact job within programming, it’s vital to be comfortable with basic development. The structure of a coding dojo, with its focus on deliberate practise and review makes a good environment for learning. This is important for new Java developers, but there are also valuable insights for advanced developers – not least, practise at collaborating with people at different levels.

I’ve definitely gain from the two recent sessions, which have provoked interesting discussions on when to refactor, the place of design in TDD/agile and error checking in functions. None of these are advanced issues, but I reckon they are all vital for day-to-day work.

Another reason for attending is that the sessions are fun. You get to meet other developers and work with them. Collaborating with people from outside our own companies is a great way to learn new things.