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.
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.
Safety doesn’t happen by accident
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.
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.
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.
The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced.
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.
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?