Tomorrow is the Global Day of Code Retreat 2013, or as I like to call it, the programmers’ Christmas. Every year, I think of what I can improve in the code retreat to make it even better for the attendees. Last year, I decided to start by asking them what they would like to learn and then picked the sessions accordingly (and I started a blog post that’s in draft since last year…). It worked brilliantly. This year, I plan to explain better how to get the most out of a Code Retreat.
If you’re going for the first time to such an event, you probably will be surprised by a few things. You might feel confused and might not adapt to the event until later in the day. I hope that by reading these few recommendations you will get the most out of your first (and the other) code retreats you attend.
Here are some of the things we’ve learned about running a code retreat.
We’ve facilitated about 10 code retreats, including one with Corey Haines.The smallest one was with two (yes, two) people and the largest with about 20. Here are some of the things we learned.
Don’t try to convince people
Many developers who took part in code retreats tried to talk to their colleagues or friends and many times their answer was one of “it’s a buzzword”, “it’s not during work hours”, “it’s plain silly” etc. They were disappointed, but it’s ok. One of the core ideas about a code retreat is that the people that come choose to come. It’s on a Saturday, it starts in the morning, it takes all day long, you need to write code and it’s tiring. People coming there really want to come.