How to get the most out of a Code Retreat

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.

1. Embrace the freedom of deleting the code

First time code retreaters have a hard time deleting the code the first and second time. Sometimes more. In your every day work, you want to finish the problem. You want to solve it. What good is if you throw your code away?

On the other hand, in your every day work, you probably have to deal with existing code that’s hard to read and difficult to change. Probably you think now and then how good it would be if you could just delete that piece of sht code and start over. A code retreat gives you this freedom. While it’s hard at first (because it’s *your code and you’ve just written it), it’s also liberating. Embrace this freedom! Delete the code and figure out how to write it better the next time!

2. Do what you always wanted, but didn’t have the time

Many attendees tell me in the beginning that they would like to try TDD or pairing or learn more about design. You can do that at a code retreat, and more. Actually, if you wanted to try a technique, this is the place to try it. Ask who would like to pair with you to learn it. Tell your partners what you want to try. In return, accept what they want to try. If you want, pick something else than what the facilitator asked. This is your day, you are free to try whatever you cannot try in your daily work.

3. Get out of your comfort zone

There are circumstances when you feel comfortable. There are circumstances when you feel scared. There’s an area between those two, where you get out of your comfort zone but not so much that you don’t know what’s going on. That’s where you want to be when attending a code retreat.

The reason is that when you’re comfortable, you’re not learning anything new. When you’re scared, you cannot learn. But the area in the middle is the golden area of learning. If you feel slightly frustrated, that’s great. If you feel your gray cells working, that’s amazing.

By the way, that’s why your code doesn’t matter. The learning remains, no matter where the code goes.

4. Pair with strangers in languages you don’t know

There are levels of programming. Some programmers can write Fortran in any language. Others can write clean code in bash scripting. I am a polyglot programmer; I know C, C++, Java, C#, PHP, python, groovy, javascript, paired with people in Scala or ruby, and plan to learn a pure functional language sometime. I can tell you that seeing the constructs available in different programming languages have helped me write better code in all of them.

At a code retreat, you have the chance to see how other people think and how other programming languages solve the same problems in different ways. Not all the answers are applicable to all languages and all contexts, but at least you will have a large pool of ideas to pick from. Variety is a good thing, even if you will still define yourself as a “programming language X” developer afterwards.

You shouldn’t stop at code retreats. An extra tip is: choose from your partners one or two people to pair with. Learn with them one hour a month after work and soon you’ll find out that your skills have greatly improved and you feel better about yourself.

5. What you learn is your responsibility

This is a hard truth to understand about code retreats. After all, you have someone in front of the room who gives you problems and who is bugging you when you don’t work harder. Isn’t he/she supposed to teach you?

I once had a participant at a code retreat who in each session’s retrospective said “I learned that python is still the best language”. At the end of the event, he said that he didn’t learn anything. My question for him was: so, why did you stay?

The code retreat facilitator has only one job: to make sure that you have the right environment to learn. It’s your job to learn, and you choose what to learn. If at the end of the code retreat you’ve learned nothing new, then you have just wasted one day. Take responsibility, follow the advice from this post, and you will get a lot more from your code retreat!

Tomorrow is Global Day of Code Retreat 2013. To all of those who will program, I salute you!

I was the first Code Retreat facilitator outside US. In 2009 Maria Diaconu and I decided to experiment with this new format that Corey Haines told us about. Since then, I’ve facilitated and attended about 30 events, public or in-company, around Europe. My brother became the co-organizer of Global Day of Code Retreat, and spread the format even more around Europe.

Photo source: http://fc01.deviantart.net/fs70/i/2010/149/c/a/Learn_To_Type_by_DEAD_SoLdIeR.jpg