Global Day of Coderetreat 2018 - My Reflection

This post is all about my experience at the Global Day of Coderetreat (GDCR), November 2018 in Melbourne, Australia.

What is a GDCR? Essentially, it’s an entire day of solving a puzzle in code with different developers and new sets of constraints that are introduced throughout the day. The idea is to push yourself out of your daily ‘comfortable’ programming language and work through a problem with different people.

The official About page also summarises it well:

Coderetreat is a day-long, intensive practice event, focusing on the fundamentals of software development and design. By providing developers the opportunity to take part in focused practice, away from the pressures of ‘getting things done’, the coderetreat format has proven itself to be a highly effective means of skill improvement. Practicing the basic principles of modular and object-oriented design, developers can improve their ability to write code that minimizes the cost of change over time.


Should you attend a GDCR?

It’s a great way to meet passionate developers that care about mastering and refining their craft. The facilitators, by design, forced us to sit with a new partner for every session during the day.

Ever feel like you’re not good enough? Excellent. Get comfortable. At first it seemed a bit daunting because the natural worst-case scenario is that you’ll be paired with a more experienced developer and you’ll feel ‘dumb’. Get over it, princess. This is the place to be. People that are attracted to attending events like this don’t come to be arseholes to everyone, and if so, it would have been dealt with in the past. I did not come across one person who was rude or disrespectful in any way. I felt that everyone in the room, experienced to novice, was there to learn. And I’m not an experienced developer yet but I tried to share my thought processes and problem solving approaches out loud with my partner each time, which is a skill in itself. The great Jon Eaves taught us to break the problem into three steps: The epic, the rules, and then a rough design. I tried to embody that.

It forces you to step out of your comfort zone

You’re working in languages you aren’t familiar with, you’re working on someone else’s laptop that you might not be familiar with, and you’re working on a problem that’s probably new to you. All of these things mean that your level of certainty is extremely low.

It’s not about finishing the problem and rushing through it, it’s about trying out an approach and tackling it in different ways. They don’t put count-down timers anywhere, you just get forty-five minutes per session. I found it very slow sometimes, but I also found it very fast at other times, almost like… ‘hey, where did the time go?’

No phones, only 1 laptop. No distractions. It’s you two working as a team.

Constraints! As mentioned, there are multiple constraints the facilitators force upon you during the day. The first session begins with no constraints - we use it to get our heads around the problem and get into the rhythm of pairing. Next, we focus on ping-pong pairing - the famous Kent Beck’s Test Driven Development techniques help us here, but it’s about putting it into practice. The next session was about pure functions, where you have to write a function that doesn’t mutate state; it’s a functional programming paradigm. Makes sense in theory but in that session I didn’t get very far. Baby steps was the next session. Mute pairing was the final session (yes - no talking!).

Stop! Delete your code!! After every session, you are forced to stop and delete all your code. Starting again fresh with your next pairing partner. This is always a bit of a laugh!

We had a retro after each session as a group: The facilitators asked how you found it, what did you learn, what would you do differently next time? A chance for people to share insights with the group.

Conways Game of Life @ SEEK

Conway’s Game Of Life

The task was to work through Conway’s Game of Life. Some of my colleagues and I previously worked through this problem in the early days of our careers as junior developers - I found it really intimidating at first but it’s pretty handy to understand the problem before you arrive. After just 10 months experience as a developer, I feel extremely confident with this problem now. I see possible solutions in my head, and especially I see the possibility of null pointer exceptions being a pain to debug if you implement a solution using a multi-dimensional array structure. There are multiple better ways to this approach, and talking to some of my colleagues, I can see that we can abstract the concept of an array away, and think about it in more object-oriented terms. This shifts the problem further away from language-specific issues and more towards solving the puzzle itself.

Solving the problem in a logical set of steps

Breaking the problem into sub-problems: I feel like my main regret during the GDCR was that I got too focused on beginning with the establishment of the board/grid in Conway’s Game of Life as my approach to the problem. It was only until I paired with someone (in Swift, FYI) that he made me realise we could actually develop in Test-Driven Development (TDD) without the board/grid at all, and start with just the rules of the game. In the back of my mind, I was skeptical, but I just wanted to see his thought process come to life and I kind of just went along with it. I don’t know how it would have looked if we kept going. Then a couple of sessions later, I paired with someone else using Java, my most preferred and familiar language and we got really stuck because I was focused on building the board/grid and instantiating it, which then meant I didn’t know what we should actually test as a starting point. It’s hard - you’re trying to see the bigger picture, make it loosely coupled, keep things encapsulated, name things well, convey intent and be able to explain what and why you’re doing to your partner all within a short time frame. But I wouldn’t trade what I do for a living for anything else - this is truly a wonderful thing being able to solve problems like this. I just feel that I didn’t tackle the problem on its head - it could have been end-of-day fatigue but a part of me wants to experiment with Conway’s Game Of Life myself in my own time for a day or so, just playing with it in different ways. I think it would be sensible to gather feedback from an architect or principal developer in the office about it too, as I learned in Apprenticeship Patterns: create feedback loops!

Programming language variety

I got the chance to start the day with Javascript: something most developers were familiar with in the room. As Tomasz pointed out: it seems that nowadays Ruby is less popular than it used to be, and Javascript is way more popular than it used to be. I’ve been using Javascript/React more and more recently at work so it’s in the forefront of my mind, even though there were some elementary things about object instantiation I had to look up (it’s not often you start a project from scratch when you’re working in enterprise software!).

Tip: when you research something you aren’t aware of, look it up as a pair. Sometimes you’ll be surprised that what you look up might be something that your partner says ‘oh, I know about that…’ and then they give you an in-person explanation. Go on the journey together, don’t use a second laptop because it’s way too distracting and doesn’t keep you focused. If someone does break the rules and pulls out their phone, it’s ok but not recommended in the retreat. As Luke said, if you see someone pull out their phone, say ‘hey, do you want a break? Let’s take 5mins together’, and come back to the problem as a team together. It’s no big deal.

After Javascript, I paired with various people in the following languages: C#, Ruby, Java and Swift. It was great to work with something I’m familiar with (Javascript and Java) but I’ve only scratched the surface of C#, Ruby and Swift prior to the day. It was just a humbling experience to work alongside others who knew these languages well and were able to teach me the language’s quirks. That was a huge benefit of attending, too. It makes new languages feel less intimidating and helps you be a more well-rounded developer with a lack of bias towards a certain way of working. I will never be the type of developer to say ‘I hate xyz language / tool / framework’. I believe everything has its pros and cons, and these facts of software development have different use cases, some more appropriate and less appropriate for different scenarios.

Being a bit of an Apple fanboy, I have this soft spot for Swift, but wow - it really surprised me how laggy Xcode is in picking up compile-time errors. The guy I paired with said he had a script on-hand in his dev folder called ‘fuxc’ - “F*** You Xcode” which clears the Xcode compile-time error cache so it can re-scan your code again. Hilarious! But of course, Xcode has nice animations when code blocks can be minimised and maximised… If only the Xcode engineers spent more time optimising compile-time errors and less time on pretty animations…

Developers group at SEEK


Kudos to the organisers of the Melbourne GDCR: Victoria, Tomasz and Luke. The event was super well-organised, run efficiently and the facilitators genuinely helped out during the day and made it about learning, even when there was some push-back in some of the retros. They kept reminding us: this is about learning, just take your time. Be willing to explore with the time you have. It was truly a great experience and I hope to attend another GDCR in future and encourage more of my work colleagues to attend. I recommend any future junior developer looking to step out of their comfort zone to try something completely different to what we do in our day jobs where we’re focused on delivery, and put yourself out there and make yourself vulnerable. You’ll be surprised that you have a lot to contribute, even as a junior developer with a sense of curiosity and willingness to give it a go.

More Info: Find your local Global Day of Coderetreat at