2015 Post-Workshop Instructor Debriefing, Round 6

This post originally appeared on the Software Carpentry website.

We held our sixth round of post-workshop debriefing last week. We discussed the Software Carpentry workshops held at the University of Arkansas, Utah State University, the University of Waterloo and the first Software Carpentry workshop ever held in Korea at the Korea Radio Promotion Association (and yes we now have lesson translated in Korean)! We were also joined by a Data Carpentry instructor who taught in a recent workshop at Espoo, Finland.

We covered a wide-range of topics, from the awesome power of using of two instructors to teach version control to how to create a warm environment where everyone feels comfortable enough to participate. The topic of two instructors with one projector (sharing the cord back and forth) or two projectors, has come up on the discuss list recently as well and feedback from all instructors that we have talked to who have tried this have said it has been a very positive experience. One experienced instructor commented that when they tried this at their last workshop it was the best Git/Github learning experience they had ever witnessed. This has been added as a suggestion in the instructors notes (see the Collaboration section).

Two projectors were also noted to be very useful outside of the version control lessons at the University of Arkansas where code was projected on a separate screen; this allowed those who fell behind to easily catch up and facilitated challenge questions.

Participation and peer programming were reported to be challenges at workshops in Finland and Korea, respectively. Cultural differences between Europe and North America were hypothesized to be one of underlying causes for lack of participation, and a less than ideal room setup (multi-level-style lecture hall) prevented effective pair programming in Korea. But when faced with such challenges, how do we work with them? What can we do to promote participation and sharing in the face of cultural or other barriers?

When we discussed this at the debrief an experienced instructor shared that he has found ice breakers on the first morning of the workshop to be important if workshop participants are from different research groups and do not know each other. As for promoting peer programming in a less-than-ideal room setup, instructors may have to be more active in encouraging students to move to sit together. Explaining the reasons for pair programming may lead to more buy-in from the students to follow these suggestions.

One other intriguing topic that arose during the debrief was the presentation of a one hour capstone example (to illustrate how all the tools we teach can be integrated together) at the end of the workshop at Utah State University. The instructors reported that the capstone lesson went over very well. Amazingly, 50% of the positive feedback from this workshop were about the capstone lesson. We are interested to hear if anyone else has incorporated the capstone lesson in their workshop and whether or not the feedback from the students was as overwhelmingly positive.

Lastly, here is a list of some of the other good ideas and things to keep in mind when teaching, which arose during the debrief:

• Walk students through help documentation, not only direct them to it.
• Show an example of using Git with an R or Python script.
• Practice live coding before the workshop.
• Have someone on the team who is familiar with Windows, Mac OS X and Linux operating system for solving configuration problems.
• Use symbolic registration fees to ensure a high attendance rate.