How a Code Retreat Taught Me to Be Comfortable Throwing Away Code
Can you believe that I passed up a beautiful August weekend, at a cottage on a pristine lake just outside Algonquin Park, to spend the day back in the hot, humid city writing code for 45 minutes at a time and immediately throwing the code away? I can hardly believe it myself.
Corey needed a place to stay in Toronto so I offered him a place chez moi (lots of room because the rest of my family was, naturally, at the cottage swimming in the pristine lake). Early Saturday morning Corey and I took the Red Rocket from my place in Kensington Market to Platespin.
After some bagels and coffee, Corey and Joe introduced us participants to the structure of the code retreat: work in focused sessions of 45 minutes; use Java because it is a straight forward language that most everyone understands; develop the code in pairs (or triples); switch pairs after each session; pick at least one thing as the learning objective for each session; and, finally, throw the code away after each session.
What? Throw away the code after each session? Delete the code from version control too?
Yep. I found it quite difficult to throw away the first session’s code. However, by the end of the code retreat I was happily throwing away my code.
The goal of a code retreat is to practice programming rather than to accomplish a programming task. The structure of the code retreat cleverly supported this goal in the following ways:
- Starting as 8:30 in the morning on a summer Saturday guarantees only keen participants who wanted to learn;
- 45 minutes is too short to complete an implementation of Conways’s Game of Life;
- While one participant characterized Java as a “baby” language, I think the choice was a good one because we didn’t spend a whole lot of time getting past basic understanding which we might have done had we chosen some other language;
- Pairing and frequent pair switching are practices that emphasise learning rather than immediate productivity;
- Because every pair was asked to choose one learning goal for each session the programming in each session felt like deliberate practice;
- Throwing away the code each time was liberating because I could start a session with a new pair without either one of us having to understand the code that we had just written in the previous session.
Here are some of the deliberate learning goals that my pairs and I chose: don’t use if statements, work inside out by implementing the survival rules for a single cell, write tests using mock objects, and work outside in by writing tests using a DSL to describe the transition from one generation to the next.
Most of the code that I wrote with my pair was awkward and not worth keeping. But that is okay. As Chad Fowler writes in his book, The Passionate Programmer, if I sit down to practice coding and nothing but elegant code comes out, I’m probably sitting near the “center” of my current capabilities instead of the edges, where a good practice session should place me.
The code retreat reminded me how important it is to make time for deliberate practice. That is, make time where it is okay to ignore the strong pull of completing tasks and instead give myself a chance to experiment, learn, and practice my craft.