Last weekend, I went to the Communitech Coding Dojo in St. Jacobs, not far from Waterloo.

Coding dojo is different from a code retreat. In a code retreat, you have the same problem all day and use each iteration to try different approaches it. The problem is usually too large to be solved in one iteration. In a coding dojo, you work on a series of challenges, called katas, each of them small enough to fit into its time segment.

We did two coding katas in the morning and one legacy code refactoring kata in the afternoon.

Rather than boring my reader with recounting every hour of the day, I want to just mention a few important from this event.

I liked the two-phase structure of the refactoring kata. Alistair and Jason designed it so that the first phase was done on paper. We read the code (working in pairs!) and marked the printouts, identifying various code smells. In the second phase, we made the actual changes to the code, covering it with tests first, them making changes while keeping the tests green.

Here is what the result of the first phase looked like:

And this is a picture of me during the second phase. This legacy code was painful to look at!

Introductions at the start of such events lead to safety. Declan pointed that out in the final retrospective. People who are new to coding dojos and code retreats may be concerned about what to expect, whether their skills are good enough, whether their questions may sound stupid, etc. They need to feel safe asking their questions and making their contributions. Think of it as “hire for attitude, train for skills”, except instead of getting hired people just show up. A circle of introductions can ensure everybody appreciates their attitudes.

Several other important points were mentioned in conversations and I can capture them here as bullet points:

• It is more difficult to identify and name code smells than to simply point to the place in the code that you want to change by refactoring.
• With more TDD experience, programmers tend to use fewer mocks.
• Eliminate duplication ruthlessly in production code, but it is much more tolerable in test code.
• Stubs and builders are a powerful combination. (The builder pattern here refers not to the GOF pattern, but to test data builders described in Growing Object-Oriented Software, Guided by Tests.) Occasional breaking changes to builders are not a real pain point.
• Don’t skip the dinner with other attendees after the coding is done!

I posted the picturestaken at this event on Flickr.