Further Thoughts on Building Better Teachers

This post originally appeared on the Software Carpentry website.

On Greg's recommendation, I just finished reading Building a Better Teacher - it was an interesting book, and a well-written story. It turns out that I completely agree with Greg's assessment of the book's lessons and the challenges facing Software Carpentry, but I very much disagree with his proposed solutions!

On the idea of having a group call to discuss how recent bootcamps have gone every other week, I suspect that this is going to run into the fundamental problem that most of us not only teach bootcamps only once or twice a year, but we also only think about teaching bootcamps once or twice a year. I don't think many people (speaking for myself as well) are going to make the time to show up for one of these calls if we're not immediately about to teach a bootcamp, when we're in "teaching mode". On the taping idea, 5-10 minutes isn't nearly long enough to learn anything useful about the flow of a lesson - especially since, as the book points out, the important skill of teaching is usually how to respond to uncertainty and perceive misunderstandings from individual students' behaviors. I doubt that we'll be able to see that in such a short slice of time.

More generally, in both cases, I think these miss the second biggest point of the book (after "good teachers can be made, but it requires coaching and practice"), which is that direct, "thick", interpersonal interactions are the way that coaching works. Big group events like this are too impersonal, in my opinion, to deal with the subtleties of learning to teach well.

But I don't think all is lost. Here are two concrete counter-proposals that I think would work better (also inspired, of course, by the book). Both are essentially built around individual bootcamp experiences, when we have instructors' attention. Some of the other comments so far on Greg's blog post have hinted at similar ideas.

1. Mentorship. This has been floated before in various forms, but I think that it's a great idea to have a handful of the instructors (senior instructors?) volunteer, or be nominated, or apply, to be a class of mentors. New instructors should be strongly encouraged (in a perfect world, required, but that's probably not feasible) to teach one of their first two bootcamps under the guidance of a mentor. The mentor will help with lesson planning, observe the lesson, help with real-time adjustments (i.e., whisper in the instructor's ear) if things are going off track, and provide feedback after the fact. This gives the new instructor the additional benefit of watching an experienced instructor frame an entire two day workshop. New instructors who really wanted to dive in deep could be encouraged to travel around to teach with a selection of several mentors.

   A sticking point would be how to select mentors and get them the additional training needed to be effective mentors. That would take some logistical work, but I think it's increasingly worthwhile to have this second "tier" of instructors as our group continues to grow. Think of those academic family trees - Greg is the "root PI", who trained a set of new PhD's at the beginning, some of whom (who wanted to put in the time and effort) started their own labs.

2. Single bootcamp jugyokenkyu. Sort of a light version of the above. At every bootcamp, the other instructors and helpers who are present should be tasked with observing (at least out of the corner of their eye) how an instructor teaches each lesson. Every instructor/helper should fill out a short, half page form at the end of a lesson telling the instructor four things - what went well from a teaching perspective and what could be improved, and what went well from a content perspective and what could be improved (always in a friendly way, of course). These are given to the instructors for review.

   Then, at the conclusion of the bootcamp, the instructors sit together for 15-30 minutes to debrief on how the bootcamp went, discussing what's on the forms as well as bigger picture items. The lead instructor then reports back a summary of this discussion - a form could be useful, but I think two paragraphs of prose written to SWC central could be better. Note that this places a bit more burden on the lead instructor while removing it from the other instructors, as compared to each instructor filling out a survey.

In both cases, what these really do is address what is at heart a question of scalability - how to create a less centralized and more networked architecture for SWC that is organized around smaller hubs and sub-groups of instructors, rather than have everything organized around a back and forth to and from the mothership, steered by Greg. Note that both of Greg's suggestions are based on a mothership-coordination model.

Of course these are just suggestions, and details could surely be improved with further discussion. Speaking of which, perhaps we should organize a "task force" of us who are particularly interested in the pedegogical aspects of Software Carpentry to put a bit more effort into addressing these challenges?