Skip to main content

Global Day of Code Retreat 2018: tackling the Game of Life at GDS

Posted by: and , Posted on: - Categories: Event

Developers working in pairs during Code Retreat

The annual Global Day of Code Retreat is an opportunity for developers around the world to take a step back from their day-to-day work and reflect on the way they practise their craft.

At the Government Digital Service (GDS), we think that’s a positive thing. Running a code retreat gives us an opportunity to improve the way we work. It also allows us to network with developers from other organisations. So at 8:30am on a cold Saturday morning in November we threw open the doors to our offices in Aldgate to welcome friends and colleagues to our first ever Code Retreat.

The main aim of the day was to practise writing code under a series of constraints. We did this by asking attendees to code a zero-player game called ‘The Game of Life’. In zero-player games, you set some initial conditions and then let the game play itself. The game does this by applying a set of rules to its starting condition, setting a new state and then applying the rules to this new state. It then repeats this forever.

It’s a good challenge because although it’s simple to explain the rules, it’s reasonably difficult for a junior developer to do. With the addition of constraints it’s almost impossible!

George Racu taking the group through the basics of the Game of Life

What we did during the code retreat

We ran 5 sessions during the day, each with a different constraint. The constraints forced us to write smaller and smaller blocks of code. It’s a valuable practice - it’s too easy to try to solve entire classes of problem in one go. Smaller methods are easier to test, and tests are the most important bits of code we write.

We used test-driven development (TDD) to write our code. TDD means writing tests before writing any code to solve a problem. It’s standard here at GDS, but a day like this gives attendees an opportunity to practice it in a pressure-free environment so that it can become more natural in a real-world scenario.

People worked in different pairs during each session to help give fresh perspectives in approaching each problem.

At the end of each session, we ran a retrospective on how everything went. This process left room for us to work, as well as reflect on what we did. It let us discuss what went wrong in an open and supportive way and allowed us to be honest about what did and did not work. It's part of the way we work at GDS and contributes to our culture of openness.

The group feeds back on the day
Participants reflecting on what went well and what did not go well during the day

Nobody successfully coded the entire game. Someone asked what the point of the game was, but that’s the wrong question. It’s almost purposefully pointless. It models very simple behaviours that have little relation to the real world. The point of the exercise was to learn how to write better code, not produce a working product.

We broke the day up with a tour of the GDS office, showing our participants what we do, how we do it and talked about our culture.

We also talked about our brilliant services, such as the award-winning GOV.UK Notify.

Reflections on the day

Many of the participants who attended were junior, and we found little variety of coding languages in the room. Most people used Java or Ruby, which meant the 2 or 3 Python developers that attended did not have many people to pair with. We’ll try to avoid that in future by asking participants what languages they can use when they sign up to the event.

We're excited to host again next year. If you attended a Code Retreat anywhere in the world and have some ideas about how we could improve ours, please let us know. You can leave a comment under this post.

We're always looking for great people to join our teams. To find out more, check out the jobs we've got available at GDS.

Sharing and comments

Share this page

1 comment

  1. Comment by Raquel posted on

    Thanks for sharing the experience, I loved it!

    From my humble experience, it's not necessary that a pair knows the same programming language. That day is also an opportunity to know other programming languages.

    For example, considering that the first driver is who knows the language and has the necessary environment:

    - If the driver follows the rule "thinking out loud", then the navigator can know what the driver is writing.
    - When they interchange their pairing roles, the navigator can help the driver to write the code.

    I encourage you to try it. It's an awesome experience and it can be very rewarding. It'll show you a strong sense of fellowship.