A Software Carpentry workshop just wrapped at the University of Washington, hosted by the eScience Institute and organized by Ben Marwick. Our great gratitude to the organizers, and also to the huge lineup of instructors: Russell Alleen-Willems, Becca Blakewood, Tracy Fuentes, Emilia Gan, Chungho Kim, Maria Mckinley, Dominik Moritz, Ana Malagon, Ben Marwick, Marina Oganyan, Jaclyn Saunders, Peter Schmiedeskamp, Thomas Sibley, Rachael Tatman, Tiffany Timbers, Sam White, Earle Wilson, helpers Esther Le Grezause and Tania Melo, and more – you all did a tremendous job (and if I missed your Twitter / GitHub / blog and you’d like it linked, ping me on Twitter or in the Science Lab IRC).
This, as one can guess from the enormous list of instructors, was no ordinary workshop. We staffed the event almost entirely with first time instructors who went through the live Instructor Training delivered by Greg Wilson, Tracy Teal, Warren Code and myself at UW last November. In order to shore up the practical skills and experience of new instructors, we wanted to get them in front of an audience for some real hands on teaching as soon as possible; I attended to help out, support the new instructors, and try to find out just how well Instructor Training is preparing people to jump in to their first workshop. The results were illuminating & encouraging.
Everyone did a fine job, and I think everyone learned a lot. But through my observations and a debrief at the end of the workshop to get the instructors to reflect on their experience, a number of recommendations came to light, both for Instructor Training proper, and how to pull off a shakedown run like this one, as we plan to do following the Research Bazaar event in Melbourne next month.
Recommendations for Instructor Training
The Cardinal Rules. In Instructor Training, we present a lot of ideas, and most of them are pretty flexible; we want new Software & Data Carpentry instructors to think about the pedagogy the workshops were founded on, but ultimately, to teach in a way that is natural and compelling to them. There are, however, a few key points that we’d like everyone to observe:
- Live Code, No Slides. As discussed in Instructor Training, live coding slows instruction down to the pace of learning, keeps the size of examples manageable for students’ cognitive load and short term memory, and lets students see both our practice, and how we recover from mistakes. Also, by live coding, we create a context that encourages students to follow along on their own machines. Conversely, when instructors went through slides or projected the lesson notes, I saw a great many students just scrolling through the same material and taking notes like a traditional lecture.
- Use The Sticky Notes. The sticky note system of ‘all good’ vs. ‘please slow down / I’d like some help’ is a great safe way for students to provide feedback to the instructor and interact with the helpers. Don’t forget to advertise them early and often, and encourage their consistent use.
- Encourage Pair Programming. Not only is pair programming demonstrated to produce better code, it creates a more social, interactive atmosphere for students, subtly introduces the value of collaborating on code, and helps prevent discouragement by making sure no one feels isolated. Encourage your students to work together, right from the first challenge.
- Check In With Your Students Often. Make sure you frequently (at least every 15 minutes) take the class’ temperature with a formative multiple choice question, or at least a thumb gauge for how everyone is feeling. Not only is this necessary in order to adapt your lesson to your students’ needs, it lets them know that we care about how well they’re doing, which is a very encouraging atmosphere to be in.
- Write The Questions Down. Don’t just call the challenge questions out; people will hear as many different things as there are students in the room. Write them on the board, cut and paste them into the etherpad, or even throw them on a slide (the one and only thing I use slides for in my teaching).
Think of these as the pep8 of Software Carpentry (and is, of course, a draft list – we should discuss and agree the points we consider core). Presenting a list of ‘if nothing else, do this’ at Instructor Training was both requested by instructors during the debrief for this event, and would have upped everyone’s game even more; without this, it seems these points sometimes got lost in the torrent of information.
Promote Material Familiarity. It is absolutely not necessary for a new instructor to be a master of every single thing in the Software Carpentry canon, not even close – but instructors reported after this event, that it would have been helpful if Instructor Training could have reinforced their knowledge of one of the units they were planning to teach. I plan to pursue this with Damien Irving in Melbourne at the upcoming Research Bazaar event; I’d like students to familiarize themselves with the content of a unit of their choice, and base their exercises during Instructor Training on that unit, so that they go home having a great deal of preparation done, and a genuine sense of familiarity with a piece of the curriculum.
Show How It’s Done. One thing that I think is missing from Instructor Training and that could really benefit new instructors, is a straight-up demo of how it’s done. At Melbourne, I’d like to include an example of someone (hopefully the masterful Damien Irving) just teaching a 30-minute chunk of SWC to demo putting it all together, so new instructors see how to confidently live code, how to use formative questions to interact with the students, what sort of things get emphasized, and how to manage the classroom. A picture of what it all looks like will clear up misconceptions, and give new instructors a target to shoot for.
Recommendations for a First Workshop
The ensemble of new instructors at UW did a fine job of piloting their first workshop; I got to sit back and watch the magic happen, and they didn’t disappoint. I would enthusiastically recommend continuing this model of following Instructor Training with a shakedown run for new instructors, with a few tweaks to ensure it runs just right:
- Maximum two new instructors per topic. We were eager to get as many people on stage as possible, and to keep the amount of material each new instructor was responsible for small, so we split the units up across several instructors each. Where this runs into trouble, is with my perpetual advice of ‘just cover what you cover, never rush’ – while this is key for making sure your students are all along for the ride, and doesn’t really cause any problems if some material just falls off the end of a unit taught by a single instructor, it becomes more problematic if a single unit is divided up among many instructors, each of whom may have to drop some material from their sub-unit, leaving students unprepared to move on to the material the next instructor planned to cover. In practice, this wasn’t really a problem with two instructors covering a single topic; three started to get chaotic. With two instructors, I would recommend they come prepared to teach the first and last two thirds of the unit, respectively – that way, there’s a big overlap in preparation, thus allowing some flexibility in situ of where the first instructor hands off to the next within a topic.
- Have an experienced MC. Make sure an experienced instructor is on hand to mind that all the details of the workshop run smoothly, keep the large roster of instructors to time, help prepare and debrief the team before and after the workshop, and just generally dispense support and high fives. This went off without a hitch at UW, but is a definite must have, in keeping with how Software Carpentry has always paired new instructors with experienced ones.
- Convene prep & debrief meetings. Before the workshop, the MC should convene a meeting to check in with new instructors, and see how prep is going, in order to answer questions and make sure the cardinal rules are clear. At an event like the one at UW where Instructor Training and the workshop proper were separated by a couple of months, this should be a couple of weeks before the workshop, when everyone is getting down to serious planning; if Instructor Training is being followed by the workshop immediately, this can be done as an add-on or in parallel to the rest of Instructor Training. Afterwards, convene a debrief meeting to discuss how things went; I went around the room and asked what the new instructors learned, what they would do differently, what we should have done in Instructor Training to better prepare them, and how their preparation went, followed by an open floor for thoughts and reflections.
- Pay special attention to demo material. With so many instructors, the coordination of where students were supposed to download demo materials from was challenging. The MC should communicate with all the instructors beforehand to assemble a zipped folder containing all the demo material, which students can download and have ready access to.
Conclusion
All told, I couldn’t be more enthusiastic for the new batch of instructors coming out of the Seattle area, as supported by the eScience Institute; the efforts of the instructors and the Institute have jumpstarted a vibrant community of practice at the University of Washington that is definitely ready to start delivering regular Software Carpentry workshops. I think it’s clear from their performance over the last two days that Instructor Training is effectively preparing them to teach, and with a few tweaks, can do even more. From the feedback I got from instructors, I also think a big first event like this is a valuable and fun way to round out how we spin up new instructors. Many thanks again to all the instructors and organizers for this event; as always, I learned a lot from this community, and I hope I can give something back in Melbourne.