HOW IT WORKS

What Is Code Retreat

The idea for code retreat was spawned at the January, 2009, Codemash Conference by Patrick Welsh, Nayan Hajratwala and me, Corey Haines. The idea was to develop a repeatable, day-long event that was focused on practicing the fundamentals of software development. The first event was held in Ann Arbor, MI, not long after the conference.

Through the course of 2009, many retreats were held, including several international ones in Iceland and Romania. The format for the day evolved over the year, based on the concrete experiences of the facilitators. While the choice of facilitator has an effect on the details of the day, the over-arching recipe remains the same.

How I Run Code Retreats

Through 2009 and 2010, I've run many retreats, both alone and with co-facilitators. We've seen certain things work and certain things that don't work. The following recipe has become my preferred formated for running code retreats:

Here are some other resources for organizing and hosting a coderetreat.

Notes

Time Breakdown

Optional Session #7

After 6 sessions, people are usually pretty tired from an unusually intense day of coding. Sometimes people are charged up to go another sessions, sometimes they feel like they want to spend the remainder of the time talking, socializing. If everyone is up for doing a 7th session, then hold the final retrospective until after that.

What To Do In Each Session

Sessions 1 and 2:

Allow pairs to get a feel for the problem domain. Not everyone has seen Conway's Game of Life before, so these two sessions allow them to wrap their head around the task. After the first session, it can sometimes be useful to discuss the idea of deleting the code. Some people might have a bit of resistance to the idea. Gently explain that those are the rules.

Session 3:

Introduce the idea of TDD As If You Meant It. This gives a focus for people to practice the very fundamentals of TDD, similar to running scales when working with a musical instrument.

Lunch (recommended):

Facilitator and experienced pairing partner show an example of doing TDD As If You Meant It on a similar problem.

Sessions 4, 5 and 6:

Continue to practice the fundamentals of TDD. If some pairs wish to look at other aspects of the problem, it is certainly permitted. The thing to remember is that the goal is not to finish the problem, but, rather, to find a particular part of development to practice.

Whatever Language You Want!

For the first year, we pushed single-language coderetreats, generally using Java as the language. It was chosen for one simple reason: almost anyone could code in it. There were coderetreats, though, held in different languages, most notably Ruby, but they were always single-language.

In Romania, though, they had different ideas. They didn't stick to the single-language format and looked at what would happen if people did it in whatever language they wanted. So, at a single coderetreat, you might have people doing it in C#, some in Java, some in Python and perhaps a few in PHP. Since introducing Maria and Alex to the idea of coderetreat in May of 2009, the Romanians went wild and started having coderetreats all the time. When I went back to facilitate one in February, 2010, it became clear that they had some great learnings to share. We dropped the 'single-language' rule that I usually go with and went with their standard multi-language version. It worked great!

Learning from them, I've dropped the general 'single-language' rule and am more than happy to have multiple languages happening side-by-side. I stress that it is important the languages are fairly main-stream, or at least familiar to both members of the pair, otherwise one person could get a bit confused on syntax, which brings us back to the whole 'coderetreat is not about learning a new language' idea.

back home