Yesterday was the Global Day of Coderetreat and I spend it like it should be spent: I visited my very first coderetreat, organized by JUG Ostfalen. The slogan of this event is “a day to celebrate passion and software craftsmanship”. I wonder why I haven’t participated in this event earlier - passion and craftsmanship are one of the best words to describe how I feel about my job as a software developer. However, in this article I want to report about the experience and what I’ve learned.
In case you haven’t heard about coderetreats before, here’s are brief introduction what it’s all about. A coderetreat is an event in which a group of software craftsmen implement a certain task over and over again to gain insight in different solutions of the task, perfect their tools and practice together. Corey Haines, an American software craftsman, declared the November 14th of every year as the Global Day of Coderetreat, a day in which coderetreats all over the world would implement Conway’s Game of Life. This way, developers from different countries can simultaneously focus on good practice, building excellent software and trying out new languages and ways to solve the problem. You can read more about the intention at globalday.coderetreat.org.
Important concepts of this event are pair programming and to revert every line of code after 45 minutes. That way, a participant can code with another developer every 45 minutes and start fresh with the things he learned from the last round.
Round 1 - Getting Started
My partner and I managed to write 5 Tests in the first round. Every line of code written just focused on architectural thoughts and how our code should be structured. We haven’t had any implementation of the actual rules that define the game of life. The reason for this was that we both had completely different approaches to the task. While I just wanted to learn as much as possible in every area (like using the IDE, learning about code structure or actually implementing the game), my partner wanted to implement the whole game as fast as possible. He also had the advantage of having implemented the game multiple times in the past.
While coding, we had several situations in which he and I just looked at each other, not understanding why the counterpart would code what he coded. That was because we had two different views of the architecture. While I favored “intelligent” cells that could decide if they would survive this round and spawn new cells, my partner favored a top-down approach in which a game class would decide these things.
What I learned: Ask your partner what his goal is. Does he just want to use a new IDE or language? Does he want to implement the whole game? This makes a huge difference.
Round 2 - “Ping Pong”
In the second round, the host decided to make things more interesting by introducing a restriction: One developer writes a new test which runs red, then the other developer implements the business logic which makes the test green and writes another red test. This is called “Ping-Pong”. While this is a great idea, my new partner and I decided to ignore this restriction. As learned from the previous round, I asked him about his goals. Surprisingly enough, he wanted to have a look at IntelliJ IDEA, which I was using. So we spent the majority of our time discussing the features of IDEA and found out a handful of shortcuts I didn’t know. In the 45 minutes we managed to write 3 tests and define a nice architecture, which we hadn’t the time to implement.
What I learned: It’s great fun for me to show a fellow developer how he can work efficiently with proper tools.
Round 3 - Immutability
Because we didn’t actually code the Game of Life, my partner from round 2 and I decided to not switch and work another round together. We pursued our goal of self-sustaining cells that decide if they would survive the round and spawn their children. To do that, each cell would have to know its neighborhood. Because we used Java, each Cell class would have a reference to 8 other cell classes. So far, so good.
As mentioned earlier, the host of the event would spice up each new round by introducing a certain restriction. In round 3, the complete code should be immutable. While immutability is a great concept and solves a lot of problems by design, it rendered my partner and I incapable of action. Our design decision of a net of cells that know each other and create new instances of themselves was incompatible with immutability. Two or more cells cannot be instantiated when they know each other, because one of them has to be created first. Because the second cell is not yet created, it cannot be referenced by the first cell. This first cell cannot be altered after the second cell was created, because it is immutable.
What I learned: Immutability is an interesting concept, but has to be given a lot of thought. Also, my partner and I noticed at the same time, that our design would not support the new constraint. It’s an interesting moment when you realize that you have to start all over again.
Round 4 - Baby Steps
One of the better known best practices has been the restriction of round 4: baby steps. After just 3 minutes, each change has to be reverted if it didn’t make all tests run green. That way, the developer is forced to split each change in very small steps that can be implemented, tested and committed in just 3 minutes.
My partner and I had some trouble cutting our changes in these small steps. Finally, we managed to get in the right state of mind and produced a nice Git log that shows how small the steps where: “Game exists” -> “Game has a cell” -> “Game can be started with a cell” -> “Game remembers its cell”.
What I learned: Practicing baby steps is a very important thing every developer should do regularly. It trains splitting big problems into smaller ones and solve these one after the other. Also, it is vital for a good developer to know as many shortcuts of his IDE as he can.
Round 5 - Switching Code Base
In the last round, my partner and I decided to implement the game logic at first. This has not been the case in the former 4 rounds, where mainly infrastructure has been build. After we had written our first simple tests, the host made us switch places to another team’s laptop and develop the code base there. This forced us to read into the logic of another team and totally change our point of view. After another 15 minutes, we switched places to another codebase we haven’t seen before. In both situations, our main problem was the lack of intent in the code. We have not been able to understand what the team before us wanted to achieve. Hence, it was quite difficult to understand the decisions in the code. Needless to say: No team has been able to implement a complete Game of Life. ;)
What I learned: First of all, I should write down the intention of what I’m going to do. If this is done in pseudo code, plain text, a drawing or good variable- and method names is not important, but it has to be done first thing you begin to think about a problem.
Conclusion
Spending a whole day with other developers doing what they and I love has been great joy. I learned a lot, met nice people and can finally say that I know what a code retreat is. Thanks to JUG Ostfalen for organizing this event!
TL;DR
I had my first Global Day of Coderetreat and learned a lot. Go visit the next coderetreat in your area! :)
