Why And How We Organize Coding Dojos

Author: Guillaume Turri-Werth

Photo by Flipsnack on Unsplash

If you are looking for a way to both have fun and improve your coding skills (or those of your team), I have some good news: we have open-sourced a repo that contains material to organize coding dojos! 🎉 👇

GitHub - criteo/coding-dojo: Some content to organize some coding dojos

Sure, there is already a lot of such material available online, but this one is still original. I’ll explain why in a minute. Before that, I need to explain how we proceed with coding dojo at Criteo, and share the good practices that help us, in our setup, organize regular coding dojos, and keep the momentum for several years. But even before that, I probably should explain what coding dojos are.

A lot has been said on this topic already, but I should at least ensure that people who are not yet familiar with this topic get up to speed. If you are already knowledgeable about it, you can skip the first part.

What coding dojos are

Coding dojos are basically a practice to improve developer skills.

In its most basic form it is pretty straightforward: you decide on simple a topic (for instance: implementing a simplified brainfuckinterpreter, a master-mind solver, a roman calculator, …), you work on it for up to a couple of hours, and afterwards you throw away (or archive) what you did -because what matters is the journey, not the destination.

That’s basically it. Then you can adapt the practical details to what works for you. You can, for instance, practice alone, in pairs, or in a group. You can do it at home, at work with teammates, or outside of work with peers.

Photo by Brett Jordan on Unsplash

Coding dojos can serve different purposes (and are hence suitable regardless of the background of the participants):

• Getting familiar with software engineer practices -TDD, pair programming, refactoring, …
• Experimenting with unfamiliar tech stacks, such as doing a dojo in Scala as a C# engineer.
• Discovering good practices from your teammates, such as features in your IDE that you may not be aware of.
• Coaching juniors -who can be inspired by your code wizard skills.
• Developing relationships with people you don't currently work with directly.

And above all: coding dojos are fun! 💻

Our ritual

To make it more concrete, and to explain how we managed to keep the momentum during several years, I’ll give some more practical clues about how we proceed at Criteo.

Photo by Glenn Carstens-Peters on Unsplash

Before the dojo

• We have a public Slack channel that anyone can join, dedicated to the organization of coding dojos.
• We organize the dojos between 12:45 and 14:00, ensuring that many of us can attend - since we usually don’t have meetings at that time -and also because evening sessions don't work for parents. In practice:
• We have lunch between 12h and 12h30~12h45.
• And then we code together until 14h. (Keep this timing in mind, it may have some importance later 😄)
• The responsibility of the organization of the next dojo is split between two roles: one that we call the Master of Ceremony and one that we call the Master of Dojo. Those roles are assigned to volunteers. Ideally, they change every time.
• The Master of Ceremony oversees the logistics. In particular, they are responsible for booking a meeting room with a big screen, on which we can connect a laptop. At some point, that person was also in charge of ordering the lunch -it may sound like a detail, but it’s an important one, as we observed that having a budget for food really boosted participation!
• The Master of Dojo decides on which topic we will work and the stack we will use. They are also in charge of setting up a small project with no implementation and an empty test suite, but which at least builds (so we don’t waste several minutes with that boilerplate during the session).
• We set up checklists for both roles, making it less intimidating to take on those responsibilities. It is also a way to document details that ensure those roles are perfectly fulfilled -for instance, that the Master of Ceremony orders some vegetarian dishes.

During the dojo

In general, we use the format called “Randori” — a type of mob programming.

In practice, we do iterations of 5 minutes. During an iteration, a single person has the keyboard and contributes to implementing the solution. The other participants follow on the screen and give advice. At the end of the iteration, the next person takes the keyboard and continues the code where the previous participant ended the iteration.

Photo by charlesdeluvio on Unsplash

We continue like this for roughly 1h15~1h30. It is a bit short, but it fits our constraints. We try to keep between 5 and 10 minutes at the end to:

• Debrief (what did we learn? What went well? What ended up being poor decisions and how we could have proceeded differently, …)
• Get volunteers for the roles of Master of Ceremony and Master of Dojo for the next session

The good practices we identified

Launching a coding dojo initiative at work is easy, and it's exciting to be enthusiastic about it. However, we often lose momentum after a couple of months 😫. Unfortunately, we've been there a couple of times. We then managed to relaunch coding dojos and to keep the momentum alive for several years 🎉

Here are the practices that work well in our case.

• We organize dojos on a regular basis. For instance, in the past, it was every other Tuesday. Now it is more flexible as our guideline is just to ensure we organize one per month. Anything works as long as it’s not “the next dojo occurs whenever someone is motivated enough to organize it” 😄
• If the duration is too short (say, less than 1h), we don’t have time to do anything interesting. If it is too long (say, more than 2h), it is hard to keep participants focused and interested. In practice, we do roughly 1h15 so people can go back to work at 2 PM. It’s a bit short, and that’s why we came up with the trick that… we’ll reveal just after 😊 (but if in your setup you can do up to 2h long dojos, it’s probably better)
• As mentioned previously, we split the responsibility of the organization. We achieve this by applying two tricks: defining two roles to organize a given session. It ensures it is not overwhelming; And we try to have different volunteers take those roles during successive sessions. That way, we have more people who know how that works, and we hence reduce the bus factor.

Photo by Afif Ramdhasuma on Unsplash

Another advantage of changing the people in charge of preparing a topic is that, over the years, we have had an interesting variety of topics. Including some interesting exotic ones (such as implementing an in-memory filesystem with a FUSE, experimenting with BDD with Cucumber or mutation testing with Pitest, or even creating music with code with Sonic Pi, …)

The resources we appreciate… and why we rolled out our own

If the Master of Dojo is inspired, it can invent topics on its own: as long as it can be explained in at most a couple of minutes to participants, it’s probably ok. And for times where it lacks imagination, we can fall back on some of those resources:

• Coding Dojo: this website contains a catalog of such topics
• cyber-dojo: This is a platform that provides tooling to do dojos remotely and collaboratively. We do not use this platform (because we already have a setup that works for us), but the neat part is that it also contains a catalog of topics
• Gilded Rose: This is a pretty nice exercise to practice refactoring. It contains a code base with several code smells. The goal is to add a feature to that code base, but to do so, the user is encouraged to refactor (and hence add tests) beforehand
• Elephant Carpaccio: a dojo to practice breaking a task into tiny slices

All this content could keep us busy for years… and it did!

But lately, we felt that for our 1h15 dojos (which is short), it was sometimes frustrating to spend “too much” time writing tests. I mean, sure, practicing TDD makes a lot of sense. But having a chance to practice other skills than just writing tests is nice too.

TDD Workflow

So, we experimented with another approach: what if the Master of Dojo was also in charge of writing a test suite before the dojo? This way, we can comment all tests beforehand. During the session, we uncomment them one by one and write the code to turn them green before uncommenting the next one.

We gave that approach a try a couple of times… and it was great! 😃 Not only does it save time, but it also leads to more fluid sessions -because it ensures there is no ambiguity with what we try to implement.

I mean, of course, it is interesting to have more classic topics once in a while (to keep practicing writing tests). But it turns out that with this approach, we are still practicing a kind of TDD -“red test, green test, refactor”. The only difference is that the participants do not write the tests. 🙂

What we open-sourced

Since it takes a bit of time to set up a topic with an existing test suite, and since we appreciate this approach, we figured out we might as well share the content prepared by our Masters of Dojo.

And that’s what we released on GitHub: a set of topics on which we worked, along with their test suite. All you need to do is clone the repository, select a topic, open the corresponding project in your IDE, and follow the instructions in the associated README.

GitHub - criteo/coding-dojo: Some content to organize some coding dojos

For now we have only a handful of topics (mostly in C#, and a bit in Java), but we will keep adding the content we will produce.

Of course, we would also gladly accept pull requests that would either add topics or add support for an existing one in another language.

We hope you enjoy the content, and we would be very interested in any feedback or suggestions you might have! 👋

---