What I learnt from running a coding bootcamp

Since I started my research group 15 years ago, dozens of people trained in biology, microbiology and biochemistry have joined and graduated from the laboratory. We focus on systems biology and genomics, and coding is essential for much of our day-to-day work. So, I always dedicate resources and time to support those students who are learning how to code using popular programming languages such as R and Python. As a result, most people who graduate from my lab will know basic coding. Some of them have even become professional programmers.

This year, because we had an unusually large number of new members, I decided to put together a four-day Python-coding boot camp. My schedule was already busy, but I thought we could make the camp work by sharing the workload with members of my lab and the leader of our bioinformatics platform. After all, time invested now in teaching students to code would probably save us time in the future. The event was a success: most of the lab members took part and improved their skills. This boot camp might serve as a useful prototype for other labs in a similar position.

‘Without these tools, I’d be lost’: how generative AI aids in accessibility

I wanted my whole group to join forces so that we could all enjoy a team-building experience and learn together. The lab work was paused for a few days to make sure that most people could invest time in the boot camp. Our 24 group members all use bioinformatics to some level in their projects, but only one undergraduate student had received formal and extended coding training. A few people dedicate all their time to bioinformatics, but others mix molecular biology work and coding to various degrees. Members of two other labs who are entirely experimentation-focused joined, as well. All together, we had 25 participants.

While running the boot camp, I realized what worked well, and also noted the need for a few changes that I’ll make next time. In the following sections, I share what I did and learnt.

Structure the event around different needs

Our participants had differing levels of programming experience (we had 10 beginner coders, 11 intermediate and 4 advanced), so we dedicated the first two days to beginners. Intermediates joined on the third day, and the advanced members joined on the final day. We all used Spyder as our development environment for writing and sharing code, because it allows users to navigate objects easily side by side in the code. Some intermediate and advanced participants were helpers for the sessions dedicated to beginners, and gave lectures on topics such as basic control statements, writing functions, data analysis and data visualization. We also included a discussion on code annotation and the use of ChatGPT to help write efficient code.

On the last day, I designed some coding challenges that were specific to each level. One of these was to simulate and visualize the evolution of two gene sequences that accumulate mutations over time. This covered a lot of ground, from generating random numbers to assembling data into structures that can be parsed, to creating visuals and performing statistical analyses. At the end of that day, all teams presented their code to illustrate how they had approached their problems. This demonstrated that there are many ways to tackle any challenge, and it showed beginners that even advanced coders can sometimes encounter tricky problems. The only team that did not succeed in solving its challenge was the most advanced one — perhaps because its members had not learnt, in the previous two days, how to code as a team and split work effectively.

We built in coffee breaks in the morning and afternoon, as well as lunch breaks. In this way, we made sure that we had hands-on time for people to be active participants, share ideas about the lectures and rest between sessions.

Diversify the lectures with multiple instructors

To maximize learning, it’s better to have more than one lecturer who presents examples and teaches material. This diversifies how we explain essential concepts and can make the experience more inclusive, given that each participant has their own training and personal background that can make certain things easier or harder to grasp than they are for other people.

This multi-lecturer approach is something that my colleagues and I are encouraged to implement in our regular teaching duties, to maximize students’ learning experiences. It could be easy to overlook this aspect of teaching in a coding boot camp, and to assume that there is only one approach to training students how to code. But this is clearly not the case. For instance, many teachers focus on ensuring that participants have time to type code on their own computer and test it, because some participants will probably remember only what they tried for themselves. Other teachers prefer to emphasize understanding the conceptual aspects of coding first.

Recruit helpers who can roam the room and give advice

In addition to having several lecturers, make sure you have helpers with you. Participants sometimes do not ask for help when things do not work on their own computer, because they fear being the only ones with a specific error. As is the case in an undergraduate teaching lab with hands-on experiments, you might need people to go and look over participants’ shoulders as problems arise. That way, you can ensure that no one is left behind before you move to the next level. It is easy for students to lose track and give up when they feel that they are not following the group. Sometimes, they could be on the wrong path without realizing it, so it’s worth keeping a close eye on their work.

Use examples that are relatable to participants

Choose problems and examples that are easy for participants to understand. Learning a new language is already difficult, so try to limit the number of concepts to be learnt other than coding. If you work with molecular biologists, as I do, DNA is the obvious topic to be working on. Students might learn better if you start with a concrete example and generalize from there to abstract concepts, rather than presenting the fundamental concepts and then illustrating them with a real-life example.

ChatGPT for science: how to talk to your data

An unexpected benefit of these applied exercises is that those who do mostly computational work might get to learn more about how experiments work. Working on these problems sets up a good platform for discussion and for clarifying questions that these advanced members might have.

Teach students how to think about code before they learn how to write it

Emphasize planning over starting to write code. Most participants do not know how to organize instructions for a computer. I found that, usually, it’s not the coding syntax that’s the challenge for new programmers. Rather, it’s how to structure the code so that the computer does what they want it to do. For example, one issue we faced during the boot camp was getting participants to think about organizing their code into modules or functions that could be developed independently, rather than having it as one long list of operations.

Writing first in pseudocode (a list of instructions for the computer in a person’s own language) is a powerful solution. The programming language itself is often not the issue. This is why it is easier to learn a new coding language if you know one already – even if the syntax is entirely different.

Split large groups into smaller ones to encourage active participation

If you are working with a big group, split it into smaller teams of two to four people, and use separate rooms. In a smaller team, it is easier to value input from everyone, and less intimidating for beginners.

Organizing such an intense course from scratch was exhausting, because we had to coordinate many people and prepare teaching material in advance, as well as keeping track of everyone’s progress. However, seeing people gain confidence and be able to write their own bits of code, and then explain them to others, was immensely gratifying and made me want to repeat the idea next year.

Before we started the boot camp, I told my team that we would judge our success on how the beginners performed on the last day, not on how the advanced coders improved. I think it worked very well. Everyone could contribute to the challenges on the last day by providing input into the code design and writing some bits of code. A boot camp is only as good as the progress that the most novice participants achieve. They are the ones for whom learning on their own would probably be the most challenging, so it is they who would probably benefit the most from boot camps such as this.

Some people who said at the start of the boot camp that they were beginning from scratch could write functional code by day four, and think about building functions to make it work. One beginner told me that their thinking about how code works has improved hugely, and that they now have more versatility when programming.