The Coding Dojo


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.


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.


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?


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 .


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#.

  • A coding dojo is an interesting idea. I try to find random interview questions to solve or programming challenges found on or Staying sharp beyond what is needed for our day to day coding lifes is essential.

    • Thanks for the suggestions, Bobby. I haven’t seen the reddit link before – I will definitely check it out.

  • Hey Todd,

    Great advice! I’ve been running dojo’s successfully in various departments / businesses. We tended to run them initially every 2 weeks but that ended up proving a tall order. We eventually settled on anything between 4-8 weeks depending on the complexity of the dojo we decided on.

    Rather than pick out standard algorithms we would make up our own dojo exercises so they’re purely original content. We’ve started a repository on Github that contains them all over at:

    Our intention is to collaborate with other companies and produce more and more dojo content we can share. I figured if each company contributes we’ll have some super interesting challenges that are very different from the normal FizzBuzz / Bowling Kata’s that you normally get.

    I wrote a lengthy blogpost guide on how to run effective dojo’s over on my blog. Feel free to check it out:

    I’m looking at re-implementing dojos at my current work as a new initiative. We’ll see how that pans out!

    Thanks again – interesting read…

    • Wow – thanks for the great suggestions! I will definitely take a look at your post and exercises. And, if we create any new ones that we can share, I will definitely issue a pull request.

  • Aaron Evans

    Great idea. Especially testers need to work on their development craft, and maintaining crappy automation is no way to improve it.

    • Hi Aaron. Thanks for your comment.

      I am glad you brought up testers — even they need to practice their skills! Actually, the same principles that are used to develop production software should also be applied to testing – things like DRY (don’t repeat yourself), YAGNI (you ain’t gonna need it), KISS (keep it simple), SOLID, etc. It will definitely help testers to keep their automation maintainable going forward.

      BTW – what framework is your company using for automation?

      • Aaron Evans

        Currently, I use Java/Selenium with a custom data driven test harness but I’ve used a wide variety of test frameworks

        I was helping another tester recently become more familiar with page objects and c# when I came across bumblebee which is how I found your blog.
        Testers who are thrust into automation often do things the hard way for lack of development skills. They’re used to the brute force approach and they often are never given time to think strategically or learn new skills.
        If testers had time to do code katas or work on other projects besides automation frameworks, not only would their automation improve but they would have much greater job satisfaction and understanding on code which would help them find more bugs.

        I’m definitely going to work hard to encourage testers to practice development skills.

        Aaron Evans
        QA consulting – test automation, tools & training