Yesterday was the Global Day of Coderetreat.
‘Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design, away from the pressures of ‘getting things done’.
You can read more about the world-wide event here. I was fortunate enough to have the opportunity to attend a locally sponsored event here in Rochester. The Meetup invite explained that we would be pair-programming Conway’s Game of Life. Since we needed our own local environments and it wasn’t known ahead of time which language we would be coding in, it was recommended that we use http://cyber-dojo.org/ since it supports a wide variety of languages and includes support for testing.
Despite reviewing the Meetup description and the Coderetreat org page, I still wasn’t entirely sure what to expect of the retreat, but I decided I should at least do some research on the game itself. Turns out it has nothing to do with the board game that I used to play as a kid. It is actually quite fascinating. Check out more information on it on Wikipedia.
Since the game was foreign to me, I looked at various ways that people used to solve the game. Most of the ones I found were visual gaming solutions and I was pretty sure we would be sticking to a CLI style solution to the problem, but I got the gist of what folks were doing to solve the bare bones logic.
. . . And then I arrived at the retreat . . . and discovered that the point wasn’t to finish creating the game at all, but rather to practice different approaches to writing code. Each round was 45 minutes long and you worked in groups of 2 or 3 folks to try and solve both the problem of coding the game, as well as sticking to the round’s constraints/theme (for example, for one round, you couldn’t pass naked primitives to your functions as arguments - you could only use them inside your functions/classes). In addition to each round’s theme, one of the rules of the retreat was TDD. Since I’ve never written a test in my life I was a bit nervous. However, writing tests wasn’t so scary after the first few rounds. The basic concept was that for each round you needed to write the test for the task before you wrote the code for the task. What I found most challenging about this approach was trying to figure out how to write a test for something that hadn’t been written yet…it meant trying to test the game without testing how the game was coded, which is a very different way of thinking than I am used to and was invaluable in terms of changing the way I look at writing code.
Another thing that really surprised me about the retreat was that we were all fairly aligned in terms of languages. Almost everyone could write code in JavaScript, Ruby or both so I had no problems working with any of the partners I paired up with. And everyone was super encouraging, kind and thoughtful so I didn’t feel like I was in over my head. It was a perfect example of MINSWAN.
I would definitely recommend that folks go to the next Coderetreat that is sponsored in their area. It was well worth the time!