2015 Post-Workshop Instructor Debriefing, Round 11

This post originally appeared on the Software Carpentry website.

We held our 11th round of instructor debriefing last week where we discussed the Software Carpentry workshops held at the University of Oslo, University of Connecticut, University of Campinas, University of the Basque Country, Lawrence Berkeley Lab, Berkeley Institute for Data Science, Murdoch Childrens Research Institute, and Oklahoma State University, as well as a Data Carpentry workshop at the National Data Integrity Conference at Colorado State University. At this debriefing we also had 3 new instructors join us (who have yet to teach a workshop but will be teaching one in the near future) to gain an insight about what works (and what doesn't) at our workshops out in the wild.

What was difficult

At this debriefing session there were several challenges that instructors reported facing during recent workshops, these include: underuse of of the Etherpad by students, students getting Git repositories confused (owner versus collaborator) because they had the same name, difficulties gauging students understanding and progress when teaching remotely and having not enough challenge or multiple choice questions for participatory learning.

Unfortunately, there is no simple solution to getting the students to embrace the Etherpad, especially if they have never used this type of technology before. Some strategies employed by instructors include using the Etherpad chat to do an ice-breaker exercise at the beginning of a workshop, letting the students know that this note-pad will remain after the workshop so that they will be able to refer back to it in the future, and getting students to paste the answers to their challenge questions into the etherpad. This last suggestion is brilliant for two reasons, one, it encourages use of the etherpad, and two, it clearly illustrates to students that there is often many ways to solve a problem with code.

Difficulties in feeling connected with students was a concern for many instructors while teaching remotely at the workshop at the University of Campinas in Sau Paulo, Brasil. Instructors reported not being able to read students' body language to see how well or not well things were going. There were also technical difficulties with the audio speaker on Day 1 of the workshop with instructors having to repeat material that had been missed. This caused confusion and the instructors covered less material than they had hoped. The students were able to follow along with the lesson material but also reported that they felt disconnected from the instructors. For more information about this remote workshop, please visit Raniere Silva's blog: http://blog.rgaiacs.com/2015/06/05/swcunicamp.html.

Thus it seems, that although remote teaching is a fantastic way to bring Software Carpentry workshops to remote regions (or places that simply don't have SWC instructors yet), we clearly need to do more to better prepare our instructors to teach remotely. We may also need to adapt our workshop style and perhaps our workshop expectations to more successfully deliver our material remotely in the future.

Finally, for difficulties, both Git and Python instructors found themselves wishing for more challenge questions. Specifically for Python, it was the longing for more multiple choice questions. These are especially useful tools to quickly probe your teaching and students learning, and gives you a chance to uncover any misconceptions that arose during a lesson. Thus, if anyone has any spare time and has Git or Python expertise - please help us out by creating some new challenge material for these lessons (especially of the multiple choice format) and submit them as a pull request.

What worked really well and we should try again

Some of the things that went really well at recent workshops were the multiple choice questions (the ones that we have and instructors used were really valued by the students), getting students to sign-up for workshops in groups of people who know each other, and using Dropbox to capture and share the code presented by the instructor.

The value of peer programming is well known and often touted by our instructors, but sometimes it is a challenge to get people talking and working together during a workshop. An example of one successful way to promote this came from a recent workshop at the Murdoch Childrens Research Institute in Melbourne where organizers/instructors strongly encouraged people to sign-up for the workshop in groups. They reported that having people who know each other at the workshop made is so that they always have someone to talk to and then have support to continue using the skills they learnt at the workshop when they get back to their labs.

Finally, instructors from Oklahoma State University synced their iPython notebook to a Dropbox share translated by nbviewer. They found that this really worked well for students who fell behind and needed to see code that was no longer on the instructors screen to catch-up, as well as for those students who wanted to review what had been covered. If Python is taught across two days, the instructor can also clean up the notebook before the start of the second day so all students can start at the same place with working code.