Global Day of Coderetreat as a Facilitator
10 March 2019 · 13 minutes to read
November 2018 I had the luck to facilitate the Global Day of Coderetreat in Utrecht for my second time. Let’s walk together through the day to see how I experienced it as a Facilitator & Observer!
1. The Background
November 2017 was my very first time as a coderetreat facilitator and I enjoyed it quite much. During that time, I’ve been also contributing to the website of coderetreat, which brought me an offer to serve the Board of Coderetreat :-) . Having been organising meetups for Utrecht JUG made me interested in organising such an event as well, given that I always always stand for the quote below:
Expose yourself in as many unknown areas as you can. The knowledge, experience and different point of views you will get is priceless.
2. The Preparation
A few days before the event, we’ve sent a mail containing all the necessary setup attendees should have prepared for the day. From our side, we were three (3) facilitators and arrived at 08:30 to prepare everything for the day.
Most of the attendees were a bit late (I mean, c’mon, it was a Saturday morning, of course they’d be late 🙂). Let’s see how did the first session go.
3. The Free Session
First of all, we needed some time to setup our environments so that attendees could actually start their day.
The first session was a free session with no restrictions at all, just so that we gradually wake up and get to know the problem and setup of the day.
Of course, I was mostly observing. After a short walk around the tables, there was something that caught my eye. There was one pair where one was taking some notes on how to best solve the problem (keeping his laptop’s screen displaying the problem’s page and the rules) and the other was the one who was actually writing the code.
The webpage, however, looks like that attendee didn’t really understand the rules.
Then I thought:
Maybe we need a better introduction to the problem next time.
Continuing my walks around the pairs, I noticed another pair using only one computer. You could say from the eyes of the person who was not the one writing the code that he was already not happy with the implementation his partner chose to follow.
Another pair spent at least 5’ on discussions around IntelliJ shortcuts
👆 maybe interesting for my friend Ko Turk who’s performing a research on the battle of IDEs 😂
In the beginning there was a participant asking lots of questions. After some time, he decided to start analysing the problem on paper.
“Can I send you a link via whatsapp or email?”
said one to his partner and then they started working on the problem. After a few minutes, the first person started writing some code, but they were still discussing about the problem and the means of their communication.
There was another pair where one seemed being frustrated from what his partner was writing. After some time, they had a discussion on the distribution of their roles. Nonetheless, you could still see that the first person was still not happy with the approach they agreed upon.
30’ passed and a pair was still discussing their way of working and how to best approach the problem.
After some 40’ one Team had already written some code and they were doing good, although their tests were still failing.
“Yes, let’s do it”
said the person from the Team which changed roles at least twice. Still analysis on the problem even after 40’.
4. The String Ping-Pong Session
4.1 The Session
That is, this session was all about ping-pong without talking. What a transition, he? From the most chilled setup to one of the most restrictive! Let’s see how it affected the mindset of the people.
Session starts and you could already say people were facing difficulties on the no talking restriction.
There was a Team that had an Italian keyboard, which apparently slowed down their communication in the beginning. That is, they started discussing the constraints again, until I reminded them about the no-talking restriction :-) .
They couldn’t really talk to each other, but you could say they were enjoying themselves.
At some point, one was writing the code and his partner was looking at him. The first person was taking his time to think about was he should write. That is definitely a point where they missed the discussion with their partner.
However, the cool part of this kind of exercise is when people are not allowed to talk and someone writes something good, their partner starts immediately smiling.
No talking means embracing more reactions; just like the instinct of survival: when one of the senses is not functioning as expected, the rest need to compensate by overdoing it.
Another Team argued. One provided an implementation the other was not happy with and he looked at the first person like:
He then took the liberty of the keyboard and started typing. So, they actually had a “silent” argument. However, in the end they came up to an agreement.
Before realising how cool it was to see a common way of approaching the problem from that Team, you could already hear some laughs from the other side of the room. Probably some Team was having fun with understanding each other without being able to talk :-)
Back to the former Team, one had to leave his partner for a few minutes due to an incoming call. By the time he returned to their desk, he didn’t look that satisfied with the code his partner wrote.
4.2 The Retro
Given the transition people had to cope with (from the free session to the string ping-pong one), the Retro of this session deserves some attention.
My very first question:
“How did you feel?”
And the answers (from different attendees):
“Like playing chess. We didn’t know what the other person was thinking about.”
“We also talked, but mostly about the syntax of Kotlin.”
“I enjoyed the first session where we were only asked to write the easiest implementations possible.”
“This exercise breaks the Team Spirit. Negative experience.”
“We used comments in the code to communicate with each other. When you’re not able to talk to each other, you need to express yourself with other means, like variable namings, comments, etc.”
“The problem was not explained well.”
“How could I delete something I don’t need anymore when I’m not allowed to talk with my partner?!”
5. The Evil Pair Programming Session
5.1 The Session
“You are restricting my implementation with the way you are writing your tests!”
- One person was giving instructions to his partner on what to do
- Discussions on setters/getters, and modifications on cells
-So, now you’re changing my test. -Yes. in order to make it work.
Continuing my walks around the desks of the different pairs gave me some more quotes (from different people) to mention here.
“You are a very good programmer.”
“Can you explain me the difference between the things you wrote?”
“You teach me a lot of new things today.”
-“I’m sorry, but that’s not the way he meant it was like. -I know what I did was good. Sorry if you cannot understand.”
5.2 The Retro
My question to start this retro was very clear:
“Which elements of the simple design you struggled the most with?”
Guess what the answers were:
“No clue. When I have a problem and I need to solve it, I just start solving it without thinking about it that much. That’s my problem and I know it.”
“I wanted to write a test that wouldn’t influence the implementation , but I couldn’t.”
“We forgot to get rid of duplicated code, because of the concept of lazy programming.”
6. The 3 Lines For Code & Test Session
6.1 The Session
The session started again with discussions around the problem and the logistics (programming language to be used, who would be writing the code, etc.).
-Can you abstract this? -WHICH ONE?
The latter was communicated with a bit of attitude.
6.2 The Retro
- “It put me in a clean code mindset.”
- “Clean code always depends on your level of knowledge on the chosen language.”
- Emphasizes on the single responsibility concept
7. The Last Session
The last session of the day was more or less similar to the first one; not in terms of restrictions, but in terms of the setup. So, we had indeed a session with restrictions, however those restrictions were followed in a more chilled setup, given the long day we had.
In the end, we had an overall retro of half an hour to discuss about the day, given the following directions/questions:
- What, if any, did you learn today?
- What, if any, did surprise you?
- What, if any, will you take to work with you tomorrow?
Repetition is the mother of learning
That is, the more we organise such events, the more we learn, so, as an outro, I have a few points which could be of your help in case you’re an organiser:
- Start the day with an introduction round with the attendees (Who are you? What do you expect from today?)
- Name labels for the attendees
- Better introduction on the problem; take some time to solely explain the problem and give examples.
- Ensure you know how to utilize your tooling. From our side, we didnt know how to zoom in a slide’s picture and we didn’t anticipate the wifi connection would not be able to handle 15 different laptops at the same time.
- Better preparation for the session together with your co-facilitators. Play the day at least twice.
- Don’t push the difficult sessions in the beginning; from our side, there was one attendee who was frustrated from the transition from a completely free session to strict ping-pong and left the event
- Ensure you explain enough on TDD, the day, etc.
9. Closing Words
Once again, it was a cool event I enjoyed a lot and I’m really grateful that I had the support of Joost and Ahmed in the organisational aspects of it. Of course, many thanks to our sponsor, CodeSquad, who provided us the venue and food for that day.
Till the next one!