Recently, I facilitated another coderetreat. As in previous retreats, the participants who experienced their first coderetreat showed a pretty similar behavior. It occurred to me, that nearly EVERY coderetreat-first-timer shows the exact same behavior. This article is about how people will act, what they will code and what they most likely will learn during their first coderetreat.

It’s important to note that the following observations are just that: observations. A coderetreat is a save environment in which trying new ways of doing things is not only welcomed, but the essence of the whole experience. Doing things differently will cause problems and errors, which is just the way it is. There is no “right” way at all.

Observation #1: Java Developers Will “Think Java”.

The very first thing most people do when they decide coding in Java is create a bunch of classes and maybe empty methods. None of the rules state that there has to be a game board class or a cell class, the rules are only about living and dead neighbor cells. Nevertheless, “Java thinking” forces developers to create several classes before even thinking about the domain logic. Developers with a more functional-programming background tend to write functions that implement the domain logic. With this approach, I saw teams that implemented all rules including a 100% test coverage in just 15 minutes.

Observation #2: Developers Try to Multi-Task.

The task of implementing Game of Life seems pretty easy, considering the relatively simple domain logic. However, especially young participants of coderetreats are having trouble with doing too much at once. Often, at least three things are done at the same time: implementing new logic, fixing some bug and refactoring. That may work, but it is making things so much more complicated. Not multitasking and concentrating on one problem, for example by using the Mikado method, seems like a hard thing to do.

Observation #3: No Theoretical Examination of the Problem.

It’s very rare to see a team starting by drawing something on actual paper. Maybe the problems provided by Game of Life are so easy that they are absolutely clear right from the start, but I doubt that. Only after a while some developers say things like “Let me draw that for you” or “What I mean is this situation” and begin to scribble. Experimenting with different constellations will make the implications of the rules of the game much easier to understand. Also, drawing something is a great communication tool.

Observation #4: Begin with Special Cases.

“What’s with the border?” is a question often heard right in the first round of a coderetreat. Seemingly, developers love to focus on hard problems, so they begin with what is usually a special situation in Game of Life: the border. Of course it’s important to decide / ask how cells should behave when they are at the frontier of the game board. But is this the most important thing to think about when not one rule is implemented yet?

Observation #5: Coderetreats are “for the Young and for the Old”.

After having facilitated quite a few coderetreats, I credit Game of Life with the great potential to fascinate junior developers as well as seasoned software craftsman. I saw experienced lead developers and architects struggle with the same problems as their young coworkers. Of course the old-timer had way more options and possibilities because of the many projects they worked in. But the special situation of having a new, unseen problem at hand seems to be special for everyone. Every coderetreat-facilitator thinking that the participants may be too experienced for this event should just try it and see what happens. Bets are that everyone involved will have a great time and learn something.

These observations show: Coderetreats are a great opportunity to learn from each other and practice the craft of software development. Go ahead and facilitate one with your friends and colleagues!

TL;DR

Some behavior patterns seem to emerge in nearly every coderetreat: Java developers will heavily rely on language-specific concepts, participants in general will try to multitask (and fail), no one is trying to think about the problem by drawing something, special cases will be focused on way too early and coderetreats are the right event for young junior developers, as well as for experienced old-timers.

(image: From Wrtlprnft from Wikipedia Germany, CC BY-SA 3.0, Link)