Saturday November 15 set the stage for Global Day of Coderetreat 2014. On this day developers from all over the world joined together to improve their craft.

Together with Stefan Hendriks I facilitated the event in Utrecht, The Netherlands. In this post I sum up the day and provide a few extra links for the participants at out location. Special thanks to Stefan for proofreading this post.

I have to admit, after the Coderetreat we did for 45 people in September this year, having 13 attendees for Global Day is really relaxing and fun! Much less intensive on the facilitators, so we even got to coding ourselves :)

Introduction

At every Coderetreat we start with a short introduction why we facilitate Coderetreats, and briefly discuss the 4 rules of simple design. Also we ask attendees to quickly introduce themselves, what languages they are interested in doing and what languages they are proficient in. This helps people in chosing their pair partners.

Each session is about an hour; we code for 45 minutes, and then have a little retrospective. The kata used in these sessions is Conway’s Game of Life. This is a great fit for the Coderetreat format because everyone can understand it, yet there are a lot of interesting aspects to coding it up. Also it is hard to finish the full kata in only 45 minutes, which helps people to refrain from the pressure of finishing it. Coderetreat is not at all about finishing a kata, it’s about practice.

In every session different constraints are applied to the way people can program. I’ll explain the constraints we used below. Remember that there are a lot more constraints, we don’t use the same ones on every coderetreat. This keeps the sessions interesting, also for coderetreat veterans.

If you’re interested in learning more about the format, please see coderetreat.org. And of course feel free to drop me a question.

Session 1: Warming Up

The first session is to get familiar with the problem domain, and to get everyone’s environment up and running.

On a Coderetreat you don’t need much; your favorite language and a single assert_true function will do. Sometimes I am still amazed at how much effort people want to put into setting up “the perfect” test library.

Session 2: No Conditionals

Programming without using a form of conditionals is tough. This is one of my favorite constraints, especially to start with. It might be mind breaking, and truly opens your mind to find other ways of coding.

When I attended a Coderetreat given by Corey Haines he explained this constrained as being about polymorphism. Conditionals are procedural polymorphism. You can substitute conditionals with either inheritance (in Object Oriented languages) or polymorphic types and function parameters (in Functional languages). Explaining the constraint like so helps people to grow a better understanding and gives them some direction. It turns out I’m not alone on this, Cory Foy wrote a blog post about this on the 8th Light blog.

The common feedback, as usual, was that it is really hard not to use if-statements and to start thinking completely different. Most pairs started finding solutions late in the session.

If you’re truly fanatic about not using if-statement, perhaps the Anti-IF Campaign is for you.

Session 3: Functional Core, Imperative Shell ala Gary Bernhardt

After lunch we first watched Gary Bernhardt’s Boundaries talk. As the topic is relatively unknown. And what’s a better introduction than the original talk anyway?! After watching the talk we shared some thoughts on it and then started the session.

In case you haven’t watched the talk, in a nutshell this constraint comes down to the following. The Functional Core is about keeping all your objects immutable. The imperative shell is a thin layer that manages state (hence is imperative) using the functional core.

The common feedback was that using immutable objects helped understanding and testing the code.

If you’re interested in learning more on this topic, I highly recommend watching Gary’s screencast. As Gary shows in Ruby you don’t have to use a fully functional language to apply some of the concepts. Jessica Kerr’s talk Functional Principles for Object-Oriented Developers explains some functional principles through Java and C# code samples.

Session 4: Mute Pairs with Evil Coder

Another one of my favorite constraints is the mute session. By not allowing pairs to talk and to only communicate through code (not comments!) we simulate pairing with future-you, say in half a year from now. How understandable is the test you write, does it actually express intent the way you think it does?

Add the evil coder role and you’ll see where your tests can be more strict. The goal of the evil coder is to find loop holes in the tests and try to push the implementation in a different direction.

Closing Circle

The overal mood in the closing circle was that we had a great day. I couldn’t agree more. The group got more intimate throughout the day, and got a lot more open. What surprised me was how eager this group was.

Again I met some great people, and had an awesome time. Thank you all for that!

“Software is eating the world”

Throughout the day we mentioned Erik Meijer’s recent talk Software is eating the world. And the One Hacker Way! response of Uncle Bob (Robert C. Martin).