Every now and then I’m asked about retreat’s, dojo’s, kata’s and other practice sessions I’m organizing. How to do, pointers, topics, time, what to make sure of, where to get problems, etc. Occasionally I myself would like one place with all the nice resources I found while poring through Internet. So, here it goes, general remarks with links to pages that are dedicated to a given type of practice.


What is the aim of the meeting? How much time you can set aside for it? What form of practice have you tried out so far? Which works best?


People will first try to solve the problem, so it’s actually good to set aside some time to let them try. It’s actually better to warn them against it, but still let them try. From my experience, one or two sessions may be spent on just trying to solve whole problem, instead of doing TDD or whatever you planned to do.


  1. TDD practice
  2. pilot coding how to solve X
  3. Mikado steps for refactoring legacy code
  4. introductory session (to patterns, language, techniques for strings or dates manipulation, etc.)


Strictly organizational

This section deals with purely organizational tips, but much depends on problem you will choose, which is discussed at length later.


Before the meeting happens, plan time, choose problem, practice it yourself and have mentors ready.

Planning time

Practising ahead helps also with time-planning. How much time is needed? Having three hours, how far can you go when pairing with someone new? When breaks should be planned? How long should one session take? How many sessions do you want to have? Food, beverages, lunch – make sure it arrives during break or you will have an interruption. Snacks are good if they are available, and if you have less than 3 hours, don’t bother with anything more.

Sessions length is especially important. 40 minutes is long. Remember, some sessions (with limitations) will be very hard and people may be exhausted after. This is especially importants for Code Retreats.

Keep in mind that you need extra time for introduction, perhaps extra time for demonstrations (dojo, prepared kata, kata and callisthenics), breaks between sessions and of course closing retrospective.

Any activity other than kata will take at least 4 hours.

Prepare what you need – IDE, language etc.

Make sure people know in advance they need to bring their IDE fully prepared – any preparation during practice time is time lost.

Pair programming demonstrates your familiarity with IDE, platform, language, libraries and – last but not least – your own keyboard. Take care of yours before the meeting, it’s a waste to configure things during.

This is especially important if you won’t have network connection (wireless often can be overwhelmed).


  • Pairs are best, threes don’t work so well, unless people know each other well. Pairing is difficult! Exponentially more so when there’s three of you!
  • Start with short introduction about that particular form of practice. What is it? What are the rules?
  • Have mentors on the site – especially when you have newbies, unfamiliar with rules, problem, etc. Mentors should make rounds and help. Choose people who are familiar with the problem, would be cool if they actually practices it beforehand and could offer advise.
  • Use timer for problematic pairing pairs – especially when groups coding are bigger than 2 people. Some are VERY reluctant to let go of that keyboard!

Session limitations

Sessions are nice, but if you want to raise the bar, try:

  1. no IF statement
  2. no mouse
  3. silent session – no speaking (also no writing to each other! no comment-writing or explaining via writing, explain your intentions via code!)
  4. 2-minute TDD cycles and git reset on failing tests
  5. 5 minute cycles and first a quick estimate: how will you go about it and how many cycles you will need for each step
  6. use only automatic refactorings of your IDE (VIM, EMACS… :P)


Closing talk is important. Ask for feedback, note it down. If you won’t, you won’t improve, and if you won’t drill for it, you’ll only get “nice meeting” but little more than that. I personally like to use small pieces of paper, asking for up to three + and -. It’s fast, and I get what I need, like:

+ nice meeting
+ facilitator
+ food
– too complex problem with too little time!
– I had bad IDE, I didn’t know I will be able to code in BrainFuck

This section depends on your preparations. For instance, if people won’t finish the problem, some may take it as a critique of their skills and will defend themselves, pushing the “responsibility” / “blame” to the fact, that problem was too hard. Alas, meeting impression will suffer. Or your rating as an organizer, will drop.

Kind of activity to choose / Problem to tackle

Choose the problem weighing in how much time you have, how many people will come, what languages they’ll want to code in, how the problem fits the aim of your meeting.

There are links available here, and I’ll try to write about problems we tackled and how they worked. Unfortunately, there’s no catalogue that nicely details what to choose when and for what level of skill. Some excercises also are harder for general purpose languages (like Java) then for specific languages with closures, idioms, lambdas and map/filtering (like Ruby).


If you have less than 3 hours, go with code kata. Anything longer should be done as either code retreat, or a full blown dojo training day, or real work-day-like session (callisthenics can fit here, so can other forms of deliberate practice).

In under two hours with less than 6 people you can do a randori.

If you have less than an hour, prepared katas are your friend.