In 2011, Substantial hosted the Seattle edition of Global Day of Code Retreat. The success of that event inspired us to host a more intimate, internal retreat last week. We had about 20 developers join us from lunch until the end of the day with the sole intent of learning new ways to approach problems from their peers.
A CODE WHAT?
At a high level, a code retreat is like soccer practice for software engineers. It's a workshop that strengthens core skills in our trade and allows us to perform better on "game day". The focus is on the process of production rather than code production itself. It is a chance to experiment with testing, pairing and refactoring code. You can delve into the finer details here.
REPETITION AND DIFFERENCE.
Once upon a time a famous French philosopher, Deleuze, gave a thesis on repetition and difference. What he suggests is fairly simple at the outset: that when something is repeated several times, small differences in each iteration become more obvious. Deleuze also points out that an awareness of these differences is something that affects growth and innovation. I like to think of Code Retreats in that light: as a repetitive exercise that reinforces a cycle of self-actualization.
OK, ok, so what’s that have to do with coding? Well, most Code Retreats focus on building and rebuilding Conway's Game of Life. The game consists of four rules and is easy to pick up. The simplicity of the game allows for tons of possible solutions and focuses the coding experience on process and approach. More journey, less destination.
We made our way through four different implementation cycles of the game. With each cycle we added a new constraint, reset our pairs, and started the code from scratch.
Cycle 1 - No Constraints
The goal of this round is to allow people to settle in. The pairs learn the details of the game and quickly come to understand that the game of life is a large problem to solve. In this round, we had one pair that produced working code/visual at the end of 45 minutes, and many more that dealt with project setup and the nuances of pairing.
Cycle 2 - TDD
The goal of this round is to introduce/reinforce the Red-Green-Refactor cycle and to have pairs focus on evolutionary design. With this addition, no one was able to finish and during retro we were able to reflect on the completing forces of speed and quality when writing software.
Cycle 3 - TDD + No Conditionals
In this round we focused on writing code without if/else blocks. Removing a commonly used feature like this make people think outside of the box. Pairs needed to use higher levels of abstraction to write the same code. In our group, people found some wild alternatives!
Cycle 4 - TDD+ Silence + Evil Coder
In this round, there were two goals. First was to have pairs communicating through expressive tests rather than talking to each other. The second goal (of the evil coder) is to write the simplest implementation possible to turn the test green. This forces the test writer to be as expressive and instructive as possible. This round caused a lot of laughter as people came up with more and more creative ways to make the test pass with ridiculous implementations.
In all, this event was beneficial for everyone at Substantial. Ideas were disseminated, minds were exercised and fun was had! The things that were most critical to our success were:
1. Engaged developers who love learning and teaching
2. A leadership team that is committed to continuous improvement of developers
3. A space in which NOT knowing the answer is safe and expected
We also took some learnings from our group retrospective and will makes these changes for the next event:
1. Add an additional round making it five total. Most people had energy for one more when we ended.
2. Expose all participants to TDD beforehand. We had a few people who were not familiar with test-driving which made the muted pairing session nearly impossible.
3. Have pairing stations set up in advance with environments for building and testing code. The hope here is to decrease setup time and also enable all participants to pair with each other (If 50% of participants bring their own computer, it means two people with computers don’t pair)
4. Provide space to discuss the problem visually. We were in our new office with limited whiteboard space, so if you are in a similar situation, have paper and pens available.
Thinking about hosting a Code Retreat and have questions? Feel free to reach out in the comments and we'll help you out.