On October 22nd, developers all over the world participated in the Global Day of Coderetreat for 2016 (GDCR 2016). GDCR is an annual event hosted by local software companies in over 100 cities around the world. Developers are invited to spend a day gaining new software development skills and honing their craft.
This year, two companies hosted free events in Auckland. We hosted one here at Movio, and the other was hosted by our friends at PushPay. While there are no strict rules, there are helpful guidelines on how the event is run. Usually, it consists of a series of sessions in which the developers work in pairs on a moderately simple yet interesting programming problem. Traditionally, Conway’s Game of Life is used as the problem of the day. Each session lasts about 30-45 minutes and the pairs’ aim is to code up an implementation within that timeframe. But there’s a catch; each session has a “constraint” which controls how the pairs may work and aims to give them tangible experience with industry best-practices. To encourage discussion, these sessions are followed by a short retrospective where everyone gathers in a circle and participants can voluntarily share highlights and insights gained from exercises in previous sessions.
An unexpected twist at each code retreat is that all code written during each of the sessions must be deleted as each session ends–much to the dismay of the participants! At first it seems absurd to delete code that may have come in handy in future, but it frees the participants to explore new ideas and take risks, without having to worry that failed experiments might embarrass them later. It also motivates them to internalise the lessons learned, and makes way for further practice in the following sessions.
The GDCR community has a traditional set of constraints that facilitators choose from, including the “evil programmer”, which aims to emphasise incremental test driven development (TDD). The pairs are each assigned two roles; the implementor, whose aim is to write the minimal implementation that will still pass the test, and the test-writer, whose aim is to write the minimal test that will require a complete implementation. Another common constraint is “mute”, where no talking or any other communication is allowed, other than the code that is written. The “mute” exercise emphasises writing clear, self-documenting code.
For our last three sessions of the day we decided to break tradition again by moving away from the Game of Life, and instead used some of the simple bite-sized CodingGame exercises. In this section, I found that participants embraced the opportunity to explore the programming languages that were unfamiliar to them. Although it focussed less on the traditional GDCR constraints and best practices, it did reenergise everyone because it brought out one of the most important aspects of software development: coding is fun! This perpetual sense of discovery and exploration is one of the biggest factors that keep software developers continuously striving to master their craft.
Find out more about joining the Movio Dev Team.