2015 Post-workshop Instructor Debriefing, Round 5

This post originally appeared on the Software Carpentry website.

At our fifth round of post-workshop debriefing this week, we discussed workshops held at the New York Academy of Sciences, the University of Oslo, and the University of British Columbia. This was a very instructive meeting with important lessons learned from the perspective of both new and veteran instructors. One of the key take-home lessons is that new instructors would benefit from attending an instructor debriefing prior to doing their first workshop.

Complete notes for this meeting can be found at https://etherpad.mozilla.org/KY6HBTIu57.

Major Lessons Learned from Debriefing Round 5

  • Good communication with the host and amongst instructors is critical for running a smooth workshop. New instructors need clear guidance on what to expect and how to plan the lessons.
  • We should remind beginning instructors that some time pressure is normal and it is not unusual to make it through less of the lesson than anticipated.
  • There is some ambiguity as to what a SWC workshop should teach and what flexibility the members deciding what is the core curriculum. We emphasized the need to base lessons on the Software Carpentrycore curriculum for consistency in Software Carpentry workshops. The consensus is that shell, Python or R and git are mandatory and there is some flexibility about including SQL.
  • New instructors and instructors transitioning from v5.2 to v5.3 could greatly benefit from participating in the instructor de-briefing meetings and seeing first-hand how the lessons are going.

New York Academy of Sciences, Mar 6-7

Website: http://mckays630.github.io/2015-03-06-nyas
Etherpad: https://etherpad.mozilla.org/2015-03-06-nyas

This workshop was run by Sheldon McKay, Jason Williams, Matthew Aiello-Lammens and Daniel Chen, with help from Jared Camins-Esakov.

  • There were 44 participants (of 55 registered) split into R (~1/4) and python (~3/4) rooms. From the pre-survey, a typical mix of novice and intermediate participants. Feedback was positive overall, with expected reference to the wifi quality and the shortage of helpers.
  • There were some particular challenges with the workshop:
    • It was not clear until the day before how many participants were registered and whether to split rooms.
    • The wifi was not up to the challenge of 40+ participants trying to download necessary files or git pull the workshiop repository.
    • There were no local helpers available, though Jared Camins-Esakov kindly came in to help in the second day.
  • All instructors used SC v5.2 lessons, with minor adaptations.
  • Set-up on day one was challenging but we adapted to having no helpers in part by enlisting the more advanced participants as ad hoc helpers. Things went smoothly overall.
  • It was very clear that we can not overemphasize how important it is for participants to do the set-up and install the prerequisites before the workshop.
  • Instructors should always carry a few thumb drives for all necessary installation files for all operating systems and a tarball of the workshop repo, with particular attention to Windows and pre-10.8 versions of Mac OS.
  • Users wanted some clear direction on post-workshop python learning materials (forums, websites, etc.).
  • The Python notebooks were a mixed bag: users appreciated a demonstration of some scripting in an IDE (used Spyder). Also need to clear run cells in the IPython Notebooks before teaching; probably best to commit the notebooks to the workshop repo in a cleared state.

Science Library, University of Oslo, Feb 26-27

Website: https://karinlag.github.io/2015-02-26-Oslo/
Etherpad: https://swcarpentry.etherpad.mozilla.org/2015-02-26-Oslo

The workshop was led by Karin Lagesen and co-instructed by Lex Nederbragt. The local helpers were excellent, and two of the four have enrolled in SWC instructor training.

  • The local IT provided excellent support and access to four pre-installed laptops for use when trainees needed them.
  • The audience was mostly STEM PhD students with some master students, postdocs, and research scientists. Of the 60 registrants, 40 were admitted but only 28 showed up (likely a consequence of not charging an entrance fee). A second workshop is tentatively scheduled for May.
  • The software installation went fine, except there were some problems with the notebook. The two screens in the class room were used for showing the Etherpad and showing the live coding. Plenty of extension cords were on hand, providing sufficient enough power. The instructors used google forms for student assessment (see the Etherpad), which worked really well when they had the time to use them.
  • Unix Shell (3 hrs): The Unix sessions took way more time than anticipated, so some of the planned materials were not taught.
  • Programming in Python (6 hrs): The instructors used v5.3 lesson, working through sections 1-4 and part of 6. The instructors had 3 concerns with the lessons.
    1. The sessions are very long and took much more time than anticipated.
    2. The example data for the sessions are not very motiving and are hard to relate to.
    3. The "right" answer is unclear even though there are many ambiguous statements about there being "something wrong" with the data. More clear explanations of the data in the instructor manual would be greately appreciated.
  • Version Control with Git (3 hrs): The Git lesson as in version 5.3 worked really well. There was some confusion over which student in the pairs owned the repo and who should push, so the instructors suggested giving a prop (such as a hat) to the owner for clarity.

University of British Columbia, Women in Science, Mar 5-6

Website: http://nsoontie.github.io/2015-03-05-ubc
Etherpad: https://etherpad.mozilla.org/2015-03-05-ubc

The workshop was taught by four instructors, three of which were first-time instructors. The forty participants were female graduate students and postdocs in the Faculty of Science; most were novices but some had R experience. There were five local helpers.

  • Setup: The installs went well (for the most part) and everyone had access to the data we needed for the workshop. Having two projectors worked really well, especially for the Git lessons. The classroom had plenty of power cords, working Wi-Fi and provided a comfortable working environment. Students didn't really use the Etherpad very much, but the instructors posted some key notes and useful URLs. As per usual, participants liked the sticky notes and appreciated the supportive learning environment.
  • Unix Shell (~0 hrs): The instructors introduced bash shell gradually, but there was no formal lesson in the bash shell. The instructors planned on using R instead of Unix. In retrospect, shell basics should have been covered formally because there was some confusion when using these commands later in the workshop.
  • Programming (8 hrs): The instructors focused on Python (5 hrs), pandas (1.5 hrs) and regular expression (1.25 hrs). Python was mostly taught from the notebook and were based on v 5.3. Pandas and regex lessons were self-developed. The rationale for using Panda was that these lessons were more motivating that those in v5.3.
  • Version Control with Git (3 hrs): The Git lesson was collaborative (using two projectors and two role-playing instructors) and it went really well. The students were excited to learn how to fork with GitHub, expressing that it's a valuable tool they will use in the future.
  • From a new instructor's perspective: The new instructors thought here is way too much material in the lessons (with the exception of Git). They suggested incorporating "exit strategies" into the lesson so that they could end with closure. Also, it was unclear about what was the required curriculum. Though they appreciate the amount of material that SWC has to offer, it is intimidating as a newbie to make the decision about what is essential to teach at a workshop and what is not. Finally, it's not always clear how to navigate the website/repo to find the pertinent material.

Dialogue & Discussion

Comments must follow our Code of Conduct.

Edit this page on Github