Posted by j.laird on 12 July 2021 - 2:00pm 

Photo by Lagos Techie on UnsplashBy Matthew Bluteau, Sarah Jaffa, Colin Sauze, Sam Haynes and Callum Rollo.

This blog post is part of our Collaborations Workshop 2021 speed blog series. 

This is part one of two blog posts. See part two.

Increasingly, researchers are expected to not only be proficient users of software but also write their own. Unfortunately and to the detriment of research code, there is no set recipe for becoming a good software developer. This is largely because many of the skills associated with software engineering/development can truly only be learned through practice.

It is a particular problem for us researchers who code and RSEs. Often we write code in isolation or small groups with little feedback on quality and design. Even in larger research groups with software development experience, the potential to improve is hampered by institutional silos that prevent the effective exchange of good practices between groups. In this environment, it is naïve to hope that good software development practices will spontaneously blossom.

Our discussion group at CW21 was interested in exploring learning mechanisms for good coding practices that are accessible to researchers and can have an immediate impact on how they work. We feel that some form of “coding club” is the best way to achieve these aims. In this blog post we discuss different types of coding clubs, how to select which is best for your target community, and suggestions for environment and community structure to support these activities.

Who Is Your Target Market?

The first consideration when starting a code club should be the community in which you think it will be viable. This will determine who you are going to invite and advertise to. If your field of work involves a lot of code, you might get enough people to form a code club just from your department or research group. On the other hand, a cross-disciplinary group, founded around a particular programming language or tool, will offer different perspectives and maybe some unexpected solutions, as well as fostering good relationships between traditionally siloed teams.

Does a community already exist? We recommend piggy-backing off of existing communities if possible. To advertise to existing communities, look for their mailing lists or online spaces. In-house bulletin boards can also be useful.

When the time comes to run an inaugural session, try to make it as convenient as possible. Some considerations:

• Avoid times that clash with seminar series or school meetings.
• Be aware that many people have caring responsibilities.
• An online event may attract more people, but presents its own challenges if any coding will be happening. Tailor this to how the community currently meets for synchronous events.
• You should also consider the age/career stage of potential members. PhD students have different time commitment capacity than senior faculty.
• Depending on their confidence level, people may be put off by a formal-sounding event that spans several hours. Start with one-hour sessions and adjust as necessary according to feedback.

What Flavour of Coding Club?

What are you actually going to do in your code club? Once you have 20 keen coders in a room, how do you approach learning new skills?

Show and Tell

One option is to get people to show each other their code, either in pairs, small groups or to the whole room. The volunteer can talk through their code and share anything they think they did well, parts they found difficult, and recommend libraries or nifty functions they use. This type of peer learning may be best if your group are all working on similar things so they can understand the code quickly. In cross-disciplinary groups you will need to encourage presenters to give a lot of background which might take too much time. This also relies on having some more experienced people in the room so they can offer more suggestions and feedback.

It can be intimidating if there is a clear division of experts vs. novices, with junior members nervous to contribute and open themselves up for criticism. You might suggest that more senior members show their code first, and do so in a humble manner acknowledging that their code is not perfect. Segregating the show-and-tell sessions by seniority/experience is also an option but that runs the risk of missing key input from more experienced coders.

Collective Problem Solving

Perhaps the most obvious activity for a coding club is to do some actual coding. Coding in groups eliminates the negative effects of coding in isolation by fostering important knowledge exchange between members. It is interesting and valuable to compare solutions from different people and different ability levels. The main advantage of this format is that members can see the benefits of techniques and skills in real time and then use them immediately themselves.

There are many different formats that a collective coding session can assume, we recommend considering the following.

1. Will the club solve domain-specific or toy problems? Domain-specific problems will help researchers feel like the sessions are directly relevant to research and therefore not a waste of time. However, these will likely only work in coding clubs where all members are from a narrow domain, and it will be more difficult to find ready-made problems. Toy problems, on the other hand, have broad applicability for inter-disciplinary clubs and are more widely available. The real value of solving problems in this setting is much less about the solution than the techniques and methods used in arriving at a solution.
2. Will the club solve problems “from scratch” or refactoring problems? Most coding problems available online involve writing the entirety of the solution from scratch. Writing new code is an essential part of the software development process, but refactoring existing code is often just as important. Refactoring problems involve taking an existing piece of code and trying to improve it by applying various refactoring techniques. This has the added benefit that beginners might be less intimidated if they don’t have to write an entire solution.
3. What format will the session be? There are two popular formats to consider. First is the “Coding Dojo” - participants are put into groups of up to 12, taking turns pair programming in front of the rest of the group. Second is the “Code Jam”, where participants split into groups of 3 or 4, each solving the same problem. It is beneficial to hold a review meeting at the end of the session so participants can see other people’s solutions. The Coding Dojo might be perceived as intimidating, but it has the benefit of getting more eyes and opinions on the code being written. Code Jams are less intimidating, but the exchange of techniques and ideas won’t be as rich. Trial and error will be necessary to see what works for your club.

Once you have answered these questions, you will need to find some coding problems to solve. The chosen problem needs to be complicated enough to keep people engaged and simple enough for beginners to tackle. Take a look at the resources in Part Two for places to find coding problems that have been tried and tested to yield positive learning outcomes.

Favourite Feature or Library

In this setting one person (or perhaps a small group) presents their favourite language feature or library, talks about it and then presents some exercises to make use of it. This typically lends itself to more experienced people presenting and requires them to put some effort into preparing materials. It’s a good way to follow up basic training (e.g. Software Carpentry courses). The format typically requires everyone to be familiar with the same programming language and for you to pitch the entire club around one language or alternate between a few popular ones. There needs to be a basic level of core knowledge from all participants and those presenting need to be aware of what level they are targeting. One problem with this approach is that it tends to put a larger burden on a few key people, often the more experienced developers or RSEs in the club.

See part two of this blog post.