Retrospective on a Remote Global Day of Coderetreat
InVision hosted a remote event for the Global Day of Coderetreat (GDCR). GDCR is an opportunity to practice software development and design in a friendly and low-pressure environment. Only a small group attended, but the results for those individuals was fantastic. At the end of the day it felt like a GDCR event and the outcomes were equivalent to other in-person GDCR events.
What Was the Format?
We had everyone initially gather in a single video conference session. This session stayed open the entire Coderetreat and simulated the main gathering area in an in-person Coderetreat. During the initial gathering we went over a slide deck that explained the day, the problem, and the tools.
After that we had a Google Sheet that had a link back to the main video conference channel, a link to a Google Doc with QA information that could be updated throughout the day, and a link to several other video conference channels. Pairing was self-organizing and after pairing up, participants would put their names next to video conference channel they would be using that session. As the facilitator I spent my time rotating between the different video conferences to simulate walking around the room.
Initially we didn’t set any specific tool for remote pair programming. That ended up being a disaster as everyone was woefully unprepared to start the first session. We ended up standardizing on VSCode with the Live Share extension. This ended up working out really well, because, as the facilitator, I was able to open up everyone’s Live Share links simultaneously and keep a pulse on who was struggling. I was still present in one video conference session at a time so I could hear and see the verbal and non-verbal communication of one pair, but I could simultaneously be getting a pulse on everyone else. I would highly recommend VSCode with the Live Share extension to anyone running a remote event.
We also setup a Slack organization so we could communicate during the day. The Live Share links were shared via Slack, but I would probably put them in the Google Sheet next to the pairs when we run the next event.
After each session everyone gathered in the main conference room and we had a retrospective. This worked really well. In addition we had the closing circle (which wasn’t much of a circle) in the main conference room.
Due to some of the hiccups along the way we only ran 4 sessions. The first session was constraint free and then we ran “3 minute TDD cycles”, “Non method members are forbidden”, and “Only four lines of code” as the constrains on subsequent sessions.
What Went Spectacularly Wrong?
We first tried to use Google Hangouts for video conferencing. None of the participants could join those Hangouts. We still don’t know exactly why, but the working theory is that we used our work email accounts and that there was some Google Domain setting that turned off sharing with people outside the org. This probably could have been avoided by just using a personal Google account when setting up the Hangouts. We ended up setting up our video conferences on our corporate Zoom accounts and everthing worked well.
I already talked about the text editor fiasco. In an onsite Codereatreat only half the people need to come prepared with a working coding environment for everyone to have a seamless experience. If everyone has a different coding environment then everything works because the pair is working on one of the member’s physical laptops. In a remote environment if both pairs don’t have the same remote coding solution then one of the people in the pair is going to have to spend some time setting up the pair’s chosen environment. This led us to standardize on one tool for everyone. When we run our next event we will standardize on one tool ahead of time and schedule some time on the day of for everyone to get it working.
We also lost the lunch experience. Between time zones and the impracticality of providing a lunch to every remote person an important part of Coderetreat was lost. We setup a break and invited everyone to grab food and eat in front of their cameras while socializing, but everyone logged out of the video conference and left until the appointed time to meet in the main conference room again. I plan on trying the eat in front of the camera idea again just to give it a second chance.
What Were the Outcomes?
One of the participants from Israel, said that he really like the way being forced to write methods that are only 4 lines long helped him to think differently. He wants to run an experiment with his team where they focus on only writing methods that are 10 lines of code or less. Another thing he said was that he liked learning how to use TDD to design instead of to just test code. He said he made the switch from “how do I test a board” to “how do I test the game”
Another participant from Texas said he wasn’t as good at TDD and Pair programming as he thought he was. He wants to practice these skills some more.
A participant from Turkey said he had never worked with someone remotely before and it was really challenging for him. He said that when we added the constraints it made life very hard. The practice showed him that he has some things to improve on.
These insights are all on par with what I would expect from an in person GDCR so that was fantastic! A couple of people wanted to make sure we run another event as part of GDCR next year and people wanting to come back is one of greatest indicators of a great event!
Conclusion
Although we had a few hiccups I think we have conclusively proven that a remote GDCR event is viable and can produce quality outcomes. Remote events are necessary because they are able to include developers that live in areas that do not have strong developer communities.
