2015 Post-Workshop Instructor Debriefing, Round 15

This post originally appeared on the Software Carpentry website.

The most recent installation of instructor debriefings by the mentoring subcommittee was held on August 4 to discuss recently completed workshops. We were joined by new instructors as well as a number of very experienced instructors (some of whom also maintain lesson repos), who all taught recently or are preparing to teach workshops. We highlight below a few of the main points from our discussions, including interesting new ideas, things that worked well, and things that were difficult.

Interesting ideas to consider

The experienced instructors in our debriefing session compared recent workshops and correpsonding materials with their previous teaching experiences. Discussions with these folks are especially important given their comparatively large sample size of how students respond to certain approaches. In particular, we talked about the benefits of slowly introducing concepts in Python and R compared to jumping right into advanced topics and explaining mechanisms as the lessons progressed. For example, the R gapminder lesson can start with impressive, powerful packages like dplyr and tidyR to motivate students. However, this can be confusing to students new to programming, and will require backtracking later in the lesson to explain more basic concepts. This problem is can sometimes be alleviated by appropriately contextualizing the point of the lesson (i.e., automation of work, rather than learning how every algorithm works). Conversations about these issues are ongoing on GitHub and in various listservs (see the novice Python lesson for an example).

Instructors for the SciPy workshop reported that a few students attended both days of the workshop without laptops, because they did not bring them to the conference. While we don't advocate this for most of our students, the students discussed material together and took notes, and seemed surprisingly satisfied with their experience. Another option is to pair students without a machine with another student who can share their screen.

What was difficult

Figuring out how to trim down copious lesson materials to fit the alloted time for a class continues to be problematic, especially for the Python and R materials (but see below). We recommend that experienced instructors partnered with new instructors for upcoming workshops share their thoughts about how to cut out sections of lessons. New instructors can also contact the mentoring subcommittee for assistance in selecting material.

What worked well

While having too much material for a topic included in the lessons can be a burden on instructors, the advantage is being able to more carefully cater the lesson to the audience. Instructors from SciPy, for example, included introductions to the packages NumPy, SciPy, Pandas, and matplotlib, because students were likely to encounter these later in the conference. More information about these lessons were written up in a previous blog post.

When making decisions about lesson designs, also consider leaving a bit of time at the end of the day (or end of workshop) to include a short capstone exercise. These exercises would ideally allow students to practice or integrate the skills learned during the course of the workshop. For example, you can close the last day in R by having students do a small data parsing exercise and visualize the result. Ideally, you should save about half an hour for students to complete such a task and bask in the satisfaction of putting their newly learned skills to work.

Dialogue & Discussion

Comments must follow our Code of Conduct.

Edit this page on Github