Summarizing Our Lesson Discussion Sessions

This post originally appeared on the Software Carpentry website.

For the first four months of this year, we ran hour-long lesson discussion sessions to give people going through instructor training a chance to ask questions of people who had taught our material several times. Trainees told us they were useful for getting information and as a way to meet more of the community. We have now decided to merge those sessions with our weekly workshop debriefing sessions in order to turn up the volume on both aspects, so this seems like a good time to summarize what we’ve learned so far ourselves.

  1. It was helpful to frame the session as a confidence building exercise rather than a test. Equally, conveying enthusiasm and answering basic questions seemed really useful, which has us asking yet again if we should record some model workshops.

  2. Aleksandra Pawlik’s guidelines were very helpful, and have now been folded into the instructor training course’s guidelines.

  3. Organizing things through an Etherpad is easy but error-prone. We are responding to this by building support for the instructor training process into AMY.

  4. The breadth of questions asked was challenging. Some people had many very specific points about certain challenge questions or pieces of demo code, while others wanted more general information about teaching, and it was sometimes difficult to satisfy both sets of needs in a single session. (Ironically, many participants’ primary concern was how to handle workshops when learners have diverse backgrounds.)

  5. The intermittent demand meant these sessions often weren’t an efficient use of instructors’ time. In particular, people often hosted sessions with only one or two people, or tried to host a session only to have scheduling issues with the one attendee who needed a host. We’re addressing this by setting a regular weekly time, which in turn makes it feasible for us to have more than one host.

  6. Despite these problems, some attendees were very happy to have one-on-one attention where they felt comfortable asking questions they feared others might find too basic. It was good to know that these new instructors weren’t falling through the cracks.

  7. Some instructors wound up fielding questions about lessons they had never taught themselves, or even ones they had never seen taught. When this happened, they tempered their advice with comments along the lines of, “You’ll come to own the lesson after you’ve taught it a couple of times.”

  8. Some instructors found that people have a somewhat passive attitute to the material, i.e., they see themselves as a vehicle for delivering set material rather than as innovators and interpreters.

  9. Most importantly, some trainees had low awareness of what actually goes on in a workshop. For example, people asked questions like whether or not people would have their own laptops, whether they were supposed to ask the challenge problems in class, and so on. This was surprising, given that most trainees are now workshop alumni, but clearly signals that we need to spend more time covering nuts and bolts in the training course.

  10. Timezones make events difficult to schedule, while daylight savings time may be the most egregiously stupid idea our species has ever implemented (and I say this as a professional programmer).

My thanks to Kate Hertweck, Bill Mills, Neal Davis, Naupaka Zimmerman, Sue McClatchy, Harriet Dashnow, April Wright, Karin Lagesen, and everyone else who helped make these sessions possible. Comments from new instructors who participated in these sessions would be very welcome.

Dialogue & Discussion

Comments must follow our Code of Conduct.

Edit this page on Github