We Tried a Code Retreat

A code retreat is a day-long activity where participants practice the craft of software development by pair-programming on a particular problem (typically an implementation of Conway’s Game of Life). The day is broken up into multiple sessions, where participants work with different people each session, and may have different constraints put on them to try and push them into different ways of thinking. At the end of each session, everyone deletes the code that they’ve written that session, we all reflect on the experience, discuss what we might do differently next time, and then everyone starts the next session with a different partner, and different constraints.

I learned about this at c’t 2024, at a talk given by Wolfram Kriesing and Marco Emrich, and I’ve wanted to try it out ever since. So when we were talking about activities for January’s monthly hackathon, I suggested it and we gave it a go.

How Did We Do It?

Code retreats have a prepared structure, which makes them relative easy to set up. There are facilitation guides available online, and lots of advice and resources from various blogs and other sites. And the key idea is to get participants to do the same task each round, which removes some of the work. The main things I prepared were the introduction — explaining the structure of the day, how test-driven development works, and the rules of Game of Life.

We had some constraints on the day that made following the normal structure more difficult. Typically, the day runs from 8:30am to 5pm, but our hackathons typically start at 9am, and we try and regroup at the end of the day between 3-4pm. In the end, due to other issues, we only managed to get in three sessions, compared to the usual five or six. We also only had five participants, so I ended up taking part as both facilitator and participant to make up the numbers a bit.

In addition, this was an in-office event, unlike a normal code retreat where people come together from different companies and places of work. This meant that we already knew each other well, and that we didn’t to think too much about choice of language or tooling — we’re a Typescript shop, so it was natural to use that, alongside Vitest and VS Code. All coming from the same place was an advantage, but potentially also a disadvantage, in that we probably didn’t have such a diverse set of approaches as if we’d been working with people from completely different areas of software development. (Although I was surprised by how diverse our different approaches were sometimes!)

What Went Well?

The code retreat format includes plenty of time for retrospectives, and we also discussed our impressions on the whole format at the end of the day. One of the positive aspects that came up in these retrospectives was the pair programming aspect. Because we often work on different topics, we don’t often get as much of a chance to program together as we’d like — we try to regularly discuss challenges with each other, but actually sitting down and programming collaboratively happens more rarely. It was a nice change to be able to work together in this way.

We also found the challenge of implementing Game of Life to be enjoyably engaging, especially in the last round where we changed some the rules and explored how it could be handled on a hex-based grid. It’s great to have the chance to experiment a bit, and write code that we wouldn’t normally be writing, in a context that’s different from our everyday work.

What Could Have Gone Better?

The goal of a code retreat is to focus on the process of writing code, and not the end goal. In practice, as a group we very quickly focused on getting to that end goal, which was a working Game of Life implementation. As the day went on, we found ourselves optimising for “time to get a working implementation”, rather than trying out different architectural and development techniques.

I don’t think this is a particularly bad thing: the goal of development is normally to write the simplest, shortest code that solves a given problem, and in practice that was what we often converged on — very simple abstractions, easy-to-work-with data structures, and simple code. But as a result, we didn’t get a chance to practice more complex skills, like building abstractions around more complicated data structures.

For us, a different task that couldn’t be solved as easily, or that had more open-ended possibilities might have worked better. Alternatively, I think practicing a more specific skill like refactoring, and having a task more focused to that (e.g. Gilded Rose or Trivia) might have worked better for us.

Conclusion

I enjoy our monthly hackathons, as it’s a great chance to stretch myself a bit and do something that I wouldn’t normally get to try out. In this case, having the chance to lead this form of workshop was new for me, and messing around with Game of Life was a good change from my everyday work.

However, for us, the Code Retreat format didn’t work very well. It was still a useful day, and we still learned plenty, but next time, we’ll probably try a different approach.