This weekend I was in Stockholm to facilitate a Code Retreat, organized by Peter Lind and sponsored by Valtech. We were about 40 coders gathered in the warm autumn sunshine early on a Saturday morning at Valtech’s offices. (Do take a look at Peter’s blog post about it, he has a photo too).

It’s actually the first time I’ve even attended a code retreat, let alone facilitated, but I think it went pretty well. Corey Haines has written extensively about what should happen, and what the facilitator should do. I think he’s given a great gift to the community, not just by inventing the format, but also by documenting it thorougly.  I’ve previously led various coding dojos and “clean code day” events, but code retreat is somewhat different in format, if not in aim.

The reason for going to a code retreat is to practice your coding skills. By repeating the same exercise over and over, with different pairing partners, you have a chance to work on your coding habits. Do you pay attention to what your tests are telling you about your design? Do you remember to refactor regularly? Can you take really small steps when you need to?

For the day in Stockholm, we followed the tried and tested formula for a code retreat that Corey has laid out. I spent about 20 minutes introducing the day, the aims and the coding problem (Conway’s Game of Life). Then we did 6 coding sessions, each with a short retrospective, and a longer retrospective at the end of the day. Each session comprised 45 minutes coding in pairs, 10 minutes retrospective in groups of 6-8, and 5 minutes to swap partners. I also began each coding session by reminding everyone of what we were supposed to be practicing, and highlighted a different “challenge” to add some variety. The challenges were things like:

– concentrate on writing really beautiful code so the language looks like it was made for the problem. *
– partition code at different levels of abstraction. **
– Think about TDD in terms of states and moves.
– do TDD as if you meant it
– concentrate on refactoring in very small steps

Each pairing session is just 45 minutes, and in that time you don’t actually have time to really solve the whole kata, and that’s actually quite difficult to cope with. Most coders are very motivated by writing code that does something useful, and like to show off their finished designs at the end. To try to prevent that, Corey emphasizes that you should keep in mind the end result isn’t important, and be sure to delete the code at the end of the session. I found that even with that rule, there was quite a lot of discussion of how the designs ended up, and some people even saved their code.

One of the things I encouraged people to try was working in an unfamiliar programming language, and although I specified “for 1 or 2 sessions”, I was surprised to find how popular it was to do this. After the first session when most people used Java, C#, Ruby or Python, there were more and more people coding in Clojure, Javascript, Erlang and even Vim script. I think it got a bit out of hand actually. It’s hard to practice your coding habits and TDD skills when you’re struggling with the language syntax and how to get the tests to run. Next time I facilitate I’ll try to be clearer about using a familiar environment for most of the sessions.

One of the things I offered in the last session was using the cyberdojo, and three pairs agreed to try it. I had them working in Java and Ruby, switching pairs every 5 minutes, coding in a browser window. They complained about the browser experience compared with their IDEs, but they liked the feedback cyberdojo gives you. It shows how long you spend between running the tests, and whether the tests pass, fail or give a compiler error.

I’m not sure if it was a good idea to bring in the cyberdojo at the code retreat. One of the main things we discussed in the retrospective for that session was the resistance they all felt to changing the first test that was written at one of the three pairing stations. This test was too big and focussed on a boring part of the problem. Yet each person who “inherited” the code tried their best to make it pass, no-one started over with a better test. It’s that kind of collaboration problem that the cyberdojo is good at highlighting. It’s not so much a tool for improving your coding skills as improving your collaboration skills. This is good, but not really the purpose of the code retreat.

Thinking back over the day, I’ve also become a little uncertain about the “delete your code” rule. I understand why it’s there, but it didn’t seem to prevent people from trying to solve the whole problem in 45 minutes. By deleting the code, you also lose the opportunity to use analysis tools like those in the cyberdojo to give you some more feedback on how you’re doing.

Outside of this code retreat, I’ve been trying out the codersdojo client quite a bit recently, to see if it gives a useful analysis of a coding session. Unlike cyberdojo, it lets you use your normal coding tools/IDE. So far it’s still in beta testing and seems too buggy for me to recommend, but if you’re lucky enough to successfully upload your coding session, you do get quite a good visualization of some of your coding habits. It will clearly show if you spend a long time between test runs, or if you spend a lot of time with failing tests.

So after my first code retreat, I’m feeling very encouraged that this is a good format for becoming a better coder, and I’d be happy to run one again. I’d like to try using coding visualization tools as part of the retrospective for each session. I’d also like to try setting the challenges before people have chosen a pairing partner, so they can find someone who also wants to work on my challenge rather than just try a new language. Or maybe I just need to emphasize more that trying a new language isn’t the focus of the day.

In any case, I hope this blog post shows that I learnt a lot from facilitating this code retreat, even if I didn’t write a single line of code myself 🙂

* “You can call it beautiful code when the code also makes it look like the language was made for the problem” — Ward Cunningham quoted in “Clean Code” by Bob Martin.
** G6: Code at Wrong Level of Abstraction – advice from “Clean Code” by Bob Martin.


  1. Adrian Bolboaca says:

    I always have at least one participant who does not want to delete the code after the session. You can see who they are after the first or maybe second session, their code is messier and they have a lot of concepts inserted that it’s clear did not come from the tests, but from a design up-front in their head. I think a reason the rule of deleting the code is to push everyone, but especially coders that want to design up-front, to see that in each session you can have another design, lead by tests. Sometimes they get illuminated during the last few sessions, sometimes they don’t, but I never try to convince anyone; these things should come from their personal experience or it’s useless.
    I think of the coderetreat like when we were little and drew with the chalk on the asphalt, and then the chalk got erased by the rain. In my view the essence is the experience, and not the result, because anyway the code after 45 minutes is in most cases awful from at least one point of view. The important thing is what remains in our head.

  2. Morten says:

    So I didn’t delete my code, neither did I look at it again during the day.

    What I did was to have each session in a branch in git, revert to the master branch when done, and start with a clean slate.

    I did this because I wanted to see the difference in my coding style across the day, and see how my solutions differed. I did not feel that my solution got messier, I did however notice how I gravitated more and more into using immutable objects and functional-programming constructs to solve the problem.

    However, I missed this but I think a good idea is to do at least one session in the language you use at work. I used programming languages I was familiar with and done at least a few hundred hours of programming in.

    I did learn quite a bit when watching solutions crumble down under the heavy weight of an overcomplicated “object oriented” approach. And how a surprising amount of people just straight to the, we need this class and that class “OOAD” thought patterns.

    I did a pairing session today with someone we might hire. To me the experience of the code retreat affected how our pairing session worked and how we did it. Thank you Emily for the dojo.

  3. Emily Bache says:

    Adrian – I like your analogy with drawing in chalk on the road. Not all art needs preserving.

    Morten – I think keeping the code for the purpose of improving your retrospective at the end of the day could be a good idea. I could be persuaded to try that I think.

    More importantly though, I’m really pleased that something from the code retreat was useful for you back at work this week!

  4. Andrew Dalke says:

    I’m going to use my age prerogative and reminisce.

    I started programming with a microcomputer which only had cassette backup. Saving programs meant finding a fresh section of tape. It was a nuisance.

    We had to learn vocabulary for Spanish class. I wrote myself a sort of flash card program to show the word in English and ask for the Spanish, or vice versa. I don’t think I ever saved the program. I wrote a new version each time, and each time it does something a bit better or a bit nicer.

    BTW, what did you use for the Life display? I still haven’t found a better solution than the hack I did at GothPy.