At Sqreen, we take training seriously. We’ve always given Sqreeners access to conferences and run community learning events in our Paris office, but, of course, the current health crisis has meant in-person events are no longer possible. To keep up our training standards during these times, and because our ProdEng team is now located in more places, we decided to run our first virtual coding dojo.
A coding dojo is an event where a bunch of software developers come together to tackle an example coding problem, sometimes referred to as a “kata.” Developers work in pairs or small teams to solve the problem, then come together at the end to review their solutions.
I’ve been a fan of coding dojos for a while. I like hands-on learning, so getting the chance to work on a new problem and share the results with fellow programmers is a great opportunity to give the old grey cells some exercise and learn some new stuff. I’ve been to many coding dojos, as both a participant and an organizer, but I’d never ran a virtual dojo before, so this too presented a learning opportunity.
What the coding dojo entailed
The aim of this coding dojo was to take two images and swap the pixels in a way that leaves the original still visible. Another way of thinking about it is recoloring the image using the palette of the second image. The problem is left deliberately open, to give the programmers some creative freedom. The full problem statement is given here: https://github.com/robertpi/pixelswap
I’d scheduled two hours for the coding dojo. I knew this was a short amount of time for this coding problem, but I didn’t want to take a bigger chunk of people’s days. The time was broken down into 15 minutes to talk through the problem statement, 1 hour and 15 minutes for free coding time, and the final 30 minutes to wrap up and compare notes.
We did the initial meeting via Zoom. As we were working individually, we moved from Zoom to Slack for the coding section. When it came to our scheduled wrap up time, most people wanted a little more time to finalize everything, so we agreed to meet the following day to present our results.
It was interesting to see that participants came up with several different categories of algorithm to approach the problem. The choice of algorithm did affect how the final image looked, but most algorithms produced similar results. The choice of algorithm has a much bigger impact on the execution time than the resulting image.
A few of the participants have made their solution to the problem public, so I won’t discuss the details of the algorithms used, but you can have a look at our solutions here: https://github.com/robertpi/PixelSwap/branches
However, I will share some of the resulting images. Two commonly used source images:
And some results:
Even with a relatively small number of participants, wrapping up in just 30 minutes was difficult — everyone had a lot to say about their code!
As I mentioned, this was my first time running an online coding dojo, so I wanted to share a few of the things I learned:
- It was good fun and a great learning opportunity, virtual events like this can work as well as in-person events
- It’s worth separating the kick-off and the wrap up over a few days, so people can choose when they work on the problem
- A virtual event makes working in teams more difficult, but I believe this can be a valuable part of the dojo learning experience, so I’ll investing more time in learning about remote pair programming
- People often have a lot to say about their code, so make sure plenty of time is scheduled for the wrap up and timebox speakers if necessary
If this dojo has interested you, feel free to give it a go yourself, full instructions are in the github repo. We’d love to see your results and hear what you think, feel free to ping me or Sqreen on Twitter.
Lastly, I’d like to thank Mathias Brandewinder who gave me the idea for the dojo when he ran it for the Paris F# user group many years ago.