This post is cross-posted from my personal blog: robertfall.com. Subscribe to my rss feed for more thoughts on tech topics.


This weekend I attended my very first code retreat, hosted by the man himself: Corey Haines, and oh my, was it an experience.

I went into the day expecting a Zen like experience of beautiful code and awesome learning. Well, the learning was there, but the code, no no, that was not beautiful. The format of all code retreats is the same and I encourage you to read about them here. Basically you are given a problem, and a time frame, that makes said problem impossible to solve. The idea is that you don’t focus on the problem, but instead on writing the absolute best code you can. You pair up and repeat the process all day, swapping pairing partners.

I think I lost the plot somewhere. As the day goes on, the problem stays the same, but the host introduces constraints, such as “No if statements or explicit loops!” or “No Primitives!” and you attempt to solve the problem. After each session you have a group discussion about how the round went and how your thoughts progressed.

The problem I had was I kept trying to do things correctly. Assuming there was a correct way was probably a little naive, but I did, and it led to a lot of frustration. I like being able to get things right, and in the process of trying to be right and learn the right way, I think I may have missed out on the Zen like experience.

That’s not to say I didn’t gain something from the weekend. I did pick up some new code smells and some design tips, as well as some really great tool knowledge from all the various pairs. Suffice to say my arrow keys are now disabled in Vim.

I remember feeling like we never got the answer though, getting flash backs to math class where the teacher would tell you what you’re doing wrong, but not how to do it right. There probably wasn’t an answer and this probably wasn’t an exercise for teaching, but rather an experience of self learning. The day was a lot of hard work and contained many hours of frustration as I struggled with the constraints.

I think what I did learn at the Code Retreat might only become apparent in time, and in subtle ways, when warning signs pop up for me that I wouldn’t have seen before, or when I find myself following the ethos behind TDD rather than just writing tests, or when I ask myself why I’m writing the test, or when I start with a lightweight top down approach instead of possibly writing something I’ll never need or when I try to minimize my red-green cycle or refactor more effectively or realise my code might be dry but the knowledge contained in it is not…

Turns out I did learn some things at Code Retreat. Fancy that.