Global Day of Code Retreat 2024 Retrospective
Whenever I can, I participate in our local software craftspeople’s Global Day of Code Retreat (GDCR) in November. Yesterday was this year’s event.
It was the first time I remember where I haven’t taken away something new for myself as a programmer.
I learned much more about people.
My mind has been occupiec with a lot of things in recent months, most of which were about our newborn baby. For me, having a child changed all priorities: the baby comes first.
It wasn’t even hard for me to shift priorities. Everything came natural – life called, and I had to answer. No thoughts or plans needed. That surprised me.
I was afraid that I had to force myself to be attentive and everything, to pry myself away from my desk. But my work is now just work. It’s fulfilling, yes; it’s nice to create something for other people, yes; but I happily put it 99th place and baby 1st without blinking.
I haven’t yet fully digested this situation and the accompanying insight.
So yesterday was Global Day of Code Retreat, and my mind hasn’t been focused on programming tasks for a while. I did write code every day, but I haven’t cared about coding that much.
During GDCR, you do pair programming in 6 sessions, with a new partner every session. A session lasts for 50 minutes plus 10 minutes break. The task is to write the Game of Life with TDD practices and pairing – and then each session introduces new twists and challenges, with the intent to make you think about this repetitive work in different ways every time.
My observations were this:
- Generational change is good for the local community. We had a ton of Java Enterprise developers in previous years. Locally speaking, Python is on the rise; but so is interest in “quirky” languages (from the perspective of Javaians) like Ruby, Elixir, Rust. I welcome that :)
- It requires leadership to work in teams. Not everyone is good at self-leading, so if nobody steps in, they can accidentally derail the team’s undertaking.
- Pair programming doesn’t come natural. I noticed that without the occasional intervention, pair programming just would not work. It’s too easy for a single mind to get absorbed into the task of writing a solution instead of responding to the actual tasks (pairing, TDD, …) for which the Game of Life is just set dressing. A simple and effective Ulysses pact is to use a timer to prevent being absorbed.
Every time I participate in a GDCR event, I wish I would work in a team. I would love to pair program more often. To bounce back ideas and crack hard problems together.
Every time I participate in a GDCR event, I’m pairing with someone who doesn’t seem to “get it”; and there’s no chemistry, so I end up losing hope in recovering the session’s focus. After all, it’ll end within the hour, so might as well leave them be, right? – I’m not sure that this is the right thing to do, though. Maybe it’s just conflict avoidance. And it’s not worth risking ruining their day if it turns out it’s just me. It’s all too easy to judge.
So the final takeaway is also this:
- It’s easy to be judgmental and dismiss others as “stupid”. It’s hard to care. Maybe they just don’t know how to detach from a problem. Maybe they’re in an Extreme Go Horse and Lone Wolf mentality not by choice, but by accident, and there could be ways to help them try something that more compatible with teams.