LessonsLearned

Many people around the world have been running coding dojos for several years now. This page is a collection of some of the lessons these people have learnt from their experiences.

These lessons use an approximation of the criteria listed in the book “Lessons learned in Software testing” (Kaner, Bach, Pettichord). A lesson should be:

• useful or provide insight
• based on actual experience
• pass the 90-minute-thinking-alone-test, ie a lesson is not worth including if almost anyone who thought about coding dojos for 90 minutes of undisturbed time could come up with it. (we’re a bit relaxed about this rule. Perhaps 10 minutes is enough)

General Lessons

• Appoint a DojoModerator - to keep discussions on track
• SetExpectations - of the DojoAttendee s so they know what to do.
• FindANewJob - some people have found a new job through dojo attendance

For meetings with a RandoriKata

• AvoidDesignThrash - next pair deletes previous pair’s design. Not good.
• Have a pc keyboard available if you’re using a mac.
• Install all needed natural language key mappings beforehand.
• At least one person present should be expert with the chosen programming language and tools (save time looking up stuff)

Practicalities

• Get someone to fund the venue and ideally food at the meetings. Eg a company sponsor, university, computer society.
• Meet regularly, at the same venue, same day of week. Not the weekend.
• Meet weekly, biweekly, or monthly.
• Most dojos seem to have 4 - 15 DojoAttendee s.
• LetItBeWorkTimeOrNot - meet late afternoon so people can either count the time as work or not as they choose

Being the DojoOrganizer

• AvoidDojoFizzleOut - Some people experience their dojos fizzle out and people stop coming after a few times.
• KataSwitchFrequency - do a new Kata every meeting, or repeat the same one until you get bored
• experiment with different DojoMeetingFormats

What are we trying to learn?

Have an overarching aim for what you are trying to learn. You can learn things like this at a dojo:

• LearningTDD
• LearningAlgorithms
• LearningRefactoring
• LearningOODesign
• LearningPairProgramming
• LearningProgrammingLanguageOrTools
• LearningCleanCode
• LearningWorkingWithLegacyCode

We could add notes to the Katas in the KataCatalogue to help people understand what they can learn from each one.