Thoughts From Running a Git Workshop

A few weeks ago, I organized and ran a workshop on Git and GitHub for the Center for Infectious Disease Dynamics at the Pennsylvania State University. I had a great time, and I think the participants did too! But now that I’ve had some time to reflect, and also in light of attending the EEID 2023 workshop on science communication, I thought it would be useful to write down some of my thoughts on the experience; notably what I think went well and what I think could be improved.

Note

I put together a companion book for the workshop, which you can find at https://psu-git.callumarnold.com, and if you find them useful, or if you have suggestions, I would love to hear from you! Either email me, DM me on twitter, or, open an issue on the GitHub repository.

What Went Well

Off the bat, I think the main thing that went well was that the participants were engaged and interested. Obviously, we had a motivated audience, but I also think this is in part because the workshop was well targeted to meet their needs. There’s a common refrain during talks that you should “know your audience”, and I think that’s true for workshops too.

Most workshops I’ve attended have done a decent job at explaining the material, but my experience with materials that accompany Git workshops is that they tend to be a little too basic, and focus a lot on specific commands using toy examples, so it becomes hard to translate the teachings to problems that you might encounter in your own work. With this in mind, I tried to use some example code that was related to the participants’ research, and I think that helped to keep them engaged. Developing an SIR model, that most were familiar with, and providing them with the code in the online book to accompany the workshop, meant that they could follow along and see how Git could be used in their own work. Another aspect of this was that the content of the accompanying book followed a realistic research flow; full of mistakes and forgotten steps that need to be amended in commits. This was further reinforced with a number of example workflows being included in the book, so the participants could read and refer back to them later as they become more comfortable using Git. This is obviously a work-in-progress, and the book will be continually updated to reflect different workflows and challenges that researchers face, but I think it was a good start.

As a related point, I think the workshop went well because I tried to focus on the why, rather than the how. Typically, there is a broad declaration of usefulness, before quickly diving into the how, which can be overwhelming. Instead, I tried to spend a large amount of time on the motivation for Git, using discussions with the participants to help them see how it could be directly applied and useful in their own work. Moving forward, I will try to incorporate this mentality into other workshops and talks that I give.

What Could Be Improved

Despite the workshop going well in general, there are a few things that I think could be improved. First, I think I could have done a better job of setting expectations for the workshop. Because we only had 2 hours, I had to make some decisions about what to cover and what to leave out. And despite personally thinking that Git gets a bad rap for being hard to learn, I underestimated how much time it would take to cover the material, which is invariably more technical than some participants were used to. On the other end of the spectrum, throughout the workshop I got a number of questions from researchers with some familiarity with Git, who were interested in more complex workflows. These individuals had tried using Git in the past, but had ultimately given up because it was too hard to actually use in their day-to-day work when collaborating with others. As a result, sections of the workshop got a little jargony and technical. To address this, in the future I will try to split the workshop into two, and do a better job of explaining the difference between the two when advertising them: one introductory workshop for those with effectively no experience, and one more advanced workshop that can address collaboration workflows.

Similarly, due to time constraints, I opted to have participants do some pre-workshop homework to get Git installed on their computers, and to create a GitHub account. The thinking was this would allow us to focus on the material during the workshop, rather than spending time getting set up. But I think this was a mistake for an introductory workshop. Although I compiled some pretty extensive instructions for how to do this, there were a number of individuals who didn’t know there were pre-requisites and read the instructions, let alone actually do them. This resulted in an awkward balancing act at the beginning of the workshop, as I tried to help some get set up, while also trying to get through the material for the rest of the participants. I could have pushed on and left them behind, but I think that also would have been a mistake, and would have made the workshop less accessible. Neither option is ideal, though, and I think the better solution is to just accept that people are busy and likely won’t have time to do work ahead of the workshop, and to plan to spend some time at the beginning of the workshop getting everyone set up.

Finally, despite the workshop being based in a relevant code example, and having an engaged audience, I think it could have been more interactive. I tried to include some exercises throughout the workshop, and had the participants work through the material, setting up a repository, making commits, and pushing to GitHub, but setting aside some dedicated time for exercises would have been better. One of the best ways to learn about code is by doing, so next time I aim to have time to do just that. For the introductory workshop, this could be very similar to what we did this time, building up a repository in chunk, but instead providing participants time to try things and get them wrong, rather than just providing step-by-step instructions. For a more advanced group, I think it would be useful to have them bring a problem to the workshop, and then work through it together, using Git to track their progress.

Takeaways

For the next workshop, I think I will try to split it into two; one introductory and one advanced, and have clearer defined expectations for each. This would allow us to get less derailed by unnecessary complexity and focus more time on grappling with the material through exercises, before working through them as a group. Overall, I think the workshop went well, and I had a great time. It was exciting to help excellent researchers learn more about reproducible computation research, and hopefully their science will benefit from it!