Recently, I and two other members of the Devolab had the opportunity to participate in an instructor training workshop for Software Carpentry and Data Carpentry. Software Carpentry is an organization that runs workshops aimed at helping scientists who can program a little improve their programming, while Data Carpentry is aimed at getting scientists with little to no programming experience started with data analysis beyond a spreadsheet. These workshops (including the instructor training) use an evidence-based, open-source teaching style that really appeals to me. Every time a pedagogical approach was mentioned, citations were provided to back it up. All of the lessons are maintained in github repositories, which everyone is encouraged to submit pull requests to (doing so is even a requirement for becoming an instructor!).
Here are three ideas that I took away from the workshop:
- Having a class take notes collectively works surprisingly well – Software Carpentry uses etherpads, online notepads which can be edited by many people at once, to record notes on each workshop. I had expected to find this distracting, but I was completely wrong. In any workshop, participants will have a range of ability levels. Having collective notes ensures that people who are struggling to get their code to run will still have a reference for what material was covered, while the people who are ahead of the curve have something to do (take notes) so that they stay engaged. Participants can also ask questions on the etherpad, which is way less distracting than having them whisper questions to their neighbors, and also gives the instructor a chance to answer them if they want.
- Sticky notes for everything! I had already seen this in action at workshops I’d helped out at in the past, but I continue to be impressed by it. At the start of each session, everyone was given two sticky notes: one red and one green. Over the course of the two day workshop, sticky notes were used for:
- Responding to quick multiple-choice questions to ensure that everyone was on the same page (hold up a color corresponding to the answer you’re selecting).
- Indicating when people had completed or needed help with an exercise (green sticky note on laptop = everything’s fine/I’ve finished, red = need help).
- Writing down feedback on the workshop (positives on green sticky notes, negatives on red ones).
- Ensuring equal participation – everyone puts three sticky notes on their laptop at the start of a discussion, and takes them down once they’ve spoken. If you don’t have a sticky note left, you can’t talk. Sticky notes get reset once everyone has used at least one.
- Empowering people matters – While Software Carpentry’s short term goal is to help scientists improve their coding skills, they have a longer-term goal of changing the culture of computation in science. Computation is becoming increasingly important across most fields of science, but it’s not like there’s magically extra time in most science curricula to teach these skills to students. As a result, students get a piecemeal introduction to computation. They don’t learn concepts that are important for doing reproducible science, such as version control. Software Carpentry can’t teach all of these skills in a two day workshop either. What Software Carpentry can do, however, is introduce students to important concepts and empower them to learn more as needed. Ultimately, the instructor training workshop is doing the same thing, but on the next level. It is reaching out to scientists with some computational skills, and empowering them to share these skills with other scientists, much like the computer science student mentorship program that I wrote about previously. The requirement that all instructors make at least one pull request to a Software or Data Carpentry git repository is an excellent example of this empowerment in action. Confession: I had never submitted a pull request before this workshop. I’ve had ideas for contributions that I could make to open source projects, but my imposter syndrome has always gotten the better of me. I worry that my code isn’t good enough, or I’ll be bothering the owners of the repository. Being told that I had to make a pull request, however small, was an invitation into the open source process. Making computational scientists feel welcome in this process is a critical step towards building a collaborative scientific community.
This workshop definitely made for a busy two days, but it was completely worth it. Also, if you’re in the Lansing area, be on the look-out for a digital evolution oriented Software Carpentry workshop at the end of the summer! We’ve encountered a number of people who want to work with Avida, but don’t quite have the computational skills needed to do so. Since those skills are exactly the set of skills that Software Carpentry workshops teach, teaching a workshop for them seems like the obvious solution.