In my post on "Being Prepared", I wrote about the need for us to practice our craft in order to deliver high quality code. Unfortunately, there are a lot of demands for our time working on projects that are under tight deadlines and supporting existing software in production.

One of the ways to escape the daily grind and focus on developing new skills is to participate in a coding dojo.

What is a Coding Dojo?

In software we do our practicing on the job, and that’s why we make mistakes on the job. We need to find ways of splitting the practice from the profession. We need practice sessions.

-Dave Thomas

A coding dojo is a periodic meeting where developers practice the craft of coding together with the object of learning how to do it better. The discussion should center around design, testing, refactoring, and tools.

Safe Environment

Safety doesn't happen by accident

-Author Unknown

Creating a safe environment is not a given. The facilitator of a coding dojo is responsible for establishing the tone by delivering an intro explaining the objective of the meeting and reminding the team that it is okay to not know something and ask questions.

Each session should have a clear objective or focus and any code produced is purely for practice and should not be leveraged for real production software. It's this aspect of throw away code that allows coders to feel safe to experiment and possibly fail while obtaining a higher level of skill.

Should managers be there?

I don't recommend that managers attend this meeting, since it is a place for actual hands-on coders to code with each other. Having participants that are merely observing or making comments without being involved with the coding might ignite a spirit of fear which would be detrimental to the learning process.

If there are hands-on managers that want to learn and code along with the team, then the team can decide whether or not to allow it.

Retrospective/Reflection

Follow effective action with quiet reflection. From the quiet reflection will come even more effective action.

-Peter Drucker

Just as in any empirical process, it is important to step back and reflect on how well things are going at the end of the session. This will allow the team to inspect their progress and adapt. Make sure to give at least 10-15 minutes for this retrospective and come away with at most 1-2 action items for the next meeting. It is also important to recognize and document the principles that the team learns during the session.

Test-Driven

Feedback is the breakfast of champions.

-Ken Blanchard

Another essential component to any dojo is the practice of writing tests in addition to the code. These will provide feedback to participants to ensure that code works as expected.

Show working

The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced.

-Aldous Huxley

Another important principle is to demonstrate how you write code - not just showing the final result of the code that you produce. The process or means is much more important than the product or the ends. This will ensure that the team learns the mechanisms for writing good code and not just what good code looks like.

This is very similar to the concept of learning by doing.

Which do you learn from more - reviewing someone's code in source control or pairing with that person to see how they produced it? How about listening to an instructor teach for hours or actually doing a lab under their supervision?

Frequency

If it hurts, do it more often.

-Jez Humble

How often should coding dojos meet?

There is no hard and fast rule to answer this question. But keep in mind that if you don't do it often enough (weekly or bi-weekly) you might not make much progress and members may become disillusioned with the process. And whatever interval the team chooses, make sure to keep it consistent so that people are willing to commit and look forward to the meetings .

Content

What should be the content of any given session?

We will discuss this topic in more detail in another post, but to begin with, consider working on a simple algorithmic problem in a tool of the team's choosing. So, for example, you might implement the Prime Factors algorithm using JavaScript. Or, you might want to implement the FizzBuzz algorithm using C#.