Published in: Uncategorised

Learning culture in software engineering teams: Coding dojos, Community of practices & Craft Workshops (6/7)

This post is part of a series of 7 blog posts on the topic How to create a learning culture for software development teams:

#10 Coding Dojos

The Coding Dojos are programming exercises to be carried out collectively. These challenges will have an educational purpose, such as practicing Test-Driven Development, or getting familiar with a particular programming language. Collections of exercises for Coding Dojo are available online, including at codingdojo.org.

There are two main formats for Coding Dojo:

Kata: One person holds the keyboard and demonstrates the exercise, taking the time to specify the points needed for the participants to understand it step by step. This person already masters the subject.
Randori: The resolution of the exercise takes place with Pair/Mob programming sessions with a rotating keyboard system. The pairs change every 5 or 10 minutes so that everyone participates. The audience can ask questions but let the pair progress without disturbing them.

For the record, the term kata refers to codified movements in martial arts, while the term Dojo refers to where martial arts are practiced. These sessions, where the repetition of techniques is used as training, will improve your skills.

Katas will often imply the practice of Test-Driven Development, as the statements of the Dojos are a series of steps to follow, reminding us of the functional increments to add to our software projects. To make sure that the requirements are met and that no regressions are created, TDD will be a natural ally.

All interested people are invited to the session. A minimum of logistics will be necessary: preparation beforehand by one or more people who have already practiced the exercise, a physical location with enough room for everyone, and timing to respect: the duration of the session will be fixed in advance (1,5 hours is fair to start), and we will keep a few minutes at the end of the workshop to debrief together. If these sessions are organized during the lunch break, we might ensure that the participants have their lunch with them when the session starts.

Therefore, the Coding Dojo is an essential part of the learning process and the development team’s skills development in an organization. It is a collective exercise that relies once again on communication, listening, transmission, and sharing.

In practice, however, we have observed several pitfalls that reflect the challenges to be faced:

The lack of capitalization on what is done and what is said during these workshops. Keeping a record of the best practices discussed during the sessions would be an added value for people who were unable to attend, for example.
The lack of interest in these workshops, where sometimes less than five people attend, even though the IT department has several hundred developers. While there are many reasons for this (logistical failures, unsuitable schedules, lack of perceived value), the dissemination of best practices proves too ineffective in such contexts.

#11 Technical communities

Technical communities, or communities of practice, are transversal structures identified with a specific topic. This model has been democratized by Spotify, with its organization by Guilds, Chapters, or Tribes. These terminologies are common in IT companies, with particular adaptations.

The topics can be generic (Architecture, DevOps) or more accurate (React or Spring). These communities are often open collective initiatives led by a group of people who naturally have a strong interest in the community’s theme and work on these subjects daily.

The proposed animations can take different forms. First of all, presentations on a specific topic:

Voluntarily by someone internal to the organization. It can be feedback on a technology implemented on a project;
Conducted by external people who come to talk about a subject relevant to the company and propose a new vision.

When these sessions take place during the lunch break, they are called BBLs (Brown-bag Launch, which refers to the brown kraft paper bag that contains the lunch we buy for lunch). You may find local Web platforms to find speakers for BBL. For instance, in France, https://www.brownbaglunch.fr/ lists at the beginning of 2022 more than 300 people that you can contact if you are interested in the topics they propose. This is a good way for your teams to get familiar with these exchange formats, and it might make some people want to suggest topics for the next time. Last important thing: don’t forget to offer food to your guest!

You can also host external communities, such as Meetups, Java User Group, who are often looking for places to host their technical presentations. This is a great way to get closer to the local Tech community.

The animation of these communities of practice is fundamental for them to last and live within the company. The more resources are allocated to their leaders to take care of them, the more the community’s sustainability will increase. Studies have highlighted the challenges for these communities of practice, for example, at Spotify. The complexity will increase for geographically distributed teams, as it will be necessary to find slots in the day that will satisfy the most significant number of people. Moreover, another challenge is meeting the community’s expectations: people will come back to the next session if they find an interest in it. And this is not always trivial when a community mixes profiles still in training and seniors.

#12 Craft Workshops

The Craft Workshops focus on the definition and sharing of knowledge for developers. The objective is to meet the limitations of the formats seen previously (capitalization, collaboration, dissemination within all teams).

The principle is simple: each developer can identify examples and counter-examples of best coding practices, either in their IDE or Web browser during a code review. We build extensions for that purpose at Promyze to easily catch these practices (as well as the proposed corrections if relevant) and centralize them. In this way, everyone can participate in creating the team’s practices repository. It is important to note that this identification should occur in the team’s working environment (code review tool, IDE). Without this prerequisite, the team will have to switch with external software to bring their knowledge, increasing the probability of reducing their adhesion to this process.

Regularly (usually once per sprint), the team or a community of practice meets by video or in-person to carry out this Craft Workshop. The objective is to review all the practices identified by developers. Each practice (as well as the associated correction) is then presented, validated or not by the team. If it is the case, it is then included in the team’s or community of practice’s repository of practice.

During this Craft Workshop, it is possible to discover best practices from other teams in the company, and enable them in your team. This brings transparency and supports knowledge sharing.

To spread these best practices efficiently and not transform the practices repository into an abandoned Wiki, we have integrated into our IDE and code review plugins a feature to automatically recognize when practices are not followed in the code, based on what is present in the examples and counter-examples in the practices repository.

Craft Workshop is therefore complementary to the methods presented above. However, it allows us to address issues that have not yet been addressed:

Capitalize on everyone’s knowledge by recording everyone’s best practices as well as concrete examples of code associated with these practices ;
Share this knowledge as a team and set up a ritual to exchange knowledge and cross our fields of expertise kindly ;
Disseminate these best practices on a large scale by allowing all the company’s teams to access practices if they relate to the same technical subject (React, for example) ;
Accelerate the onboarding and learning of these practices by taking advantage of automatic suggestions during development in our IDE or during a code review.