Building Better Teachers

BaBT's thesis is simple. Most people assume that great teachers are born, not made. From politicians to researchers and teachers themselves, most of us speak and act as if there's a gene for teaching that someone either has or doesn't. Most reforms are therefore designed to find and promote those who can and eliminate those who can't. The problem is, this assumption is wrong, so educational reforms based on it are (mostly) destined to fail. Reforms based on changing the culture of teaching would have a greater chance of succeeding, but as with any cultural change, they would require the kind of long-term commitment that our society doesn't seem to be very good at.

The book is written as a history of the people who have put that puzzle together in the US, including Nate Gage and Lee Shulman in the 1960s and 1970s, Deborah Ball, Magdalene Lampert, and others at Michigan State in the 1980s and 1990s, and educational entrepreneurs like Doug Lemov today. Its core begins with a discussion of what James Stigler discovered during a visit to Japan in the early 1990s:

Some American teachers called their pattern "I, We, You": After checking homework, teachers announced the day's topic, demonstrating a new procedure (I)... Then they led the class in trying out a sample problem together (We)... Finally, they let students work through similar problems on their own, usually by silently making their way through a worksheet (You)...

The Japanese teachers, meanwhile, turned "I, We, You" inside out. You might call their version "You, Y'all, We." They began not with an introduction, but a single problem that students spent ten or twenty minutes working through alone (You)... While the students worked, the teacher wove through the students' desks, studying what they came up with and taking notes to remember who had which idea. Sometimes the teacher then deployed the students to discuss the problem in small groups (Y'all). Next, the teacher brought them back to the whole group, asking students to present their different ideas for how to solve the problem on the chalkboard... Finally, the teacher led a discussion, guiding students to a shared conclusion (We).

It's tempting to think that this particular teaching technique is Japan's secret sauce: tempting, but wrong. The actual key is revealed in the description of Akihiko Takahashi's work. In 1991, he visited the United States in a vain attempt to find the classrooms described a decade earlier in a report by the National Council of Teachers of Mathematics (NCTM). He couldn't find them. Instead, he found that American teachers met once a year (if that) to exchange ideas about teaching, compared to the weekly or even daily meetings he was used to. What was worse:

The teachers described lessons they gave and things students said, but they did not see the practices. When it came to observing actual lessons‐watching each other teach—they simply had no opportunity... They had, he realized, no jugyokenkyu. Translated literally as "lesson study", jugyokenkyu is a bucket of practices that Japanese teachers use to hone their craft, from observing each other at work to discussing the lesson afterward to studying curriculum materials with colleagues. The practice is so pervasive in Japanese schools that it is...effectively invisible.

And here lay the answer to [Akihiko's] puzzle. Of course the American teachers' work fell short of the model set by their best thinkers... Without jugyokenkyu, his own classes would have been equally drab. Without jugyokenkyu, how could you even teach?

So what does jugyokenkyu look like in practice?

In order to graduate, education majors not only had to watch their assigned master teacher work, they had to effectively replace him, installing themselves in his classroom first as observers and then, by the third week, as a wobbly...approximation of the teacher himself. It worked like a kind of teaching relay. Each trainee took a subject, planning five days' worth of lessons... [and then] each took a day. To pass the baton, you had to teach a day's lesson in every single subject: the one you planned and the four you did not... and you had to do it right under your master teacher's nose. Afterward, everyone—the teacher, the college students, and sometimes even another outside observer—would sit around a formal table to talk about what they saw.

[Trainees] stayed in...class until the students left at 3:00 pm, and they didn't leave the school until they'd finished discussing the day's events, usually around eight o'clock. They talked about what [the master teacher] had done, but they spent more time poring over how the students had responded: what they wrote in their notes; the ideas they came up with, right and wrong; the architecture of the group discussion. The rest of the night was devoted to planning...

...By the time he arrived in [the US], [Akihiko had] become...famous... giving public lessons that attracted hundreds, and, in one case, an audience of a thousand. He had a seemingly magical effect on children... But Akihiko knew he was no virtuoso. "It is not only me," he always said... "Many people." After all, it was his mentor...who had taught him the new approach to teaching... And [he] had crafted the approach along with the other math teachers in [his ward] and beyond. Together, the group met regularly to discuss their plans for teaching... [At] the end of a discussion, they'd invite each other to their classrooms to study the results. In retrospect, this was the most important lesson: not how to give a lesson, but how to study teaching, using the cycle of jugyokenkyu to put...work under a microscope and improve it.

Putting work under a microscope in order to improve it is commonplace in sports and music. A professional musician, for example, would dissect half a dozen different recordings of "Body and Soul" or "Yesterday" before performing it. They would also expect to get feedback from fellow musicians during practice and after performances. Many other disciplines work this way too. The Japanese drew inspiration from Deming's ideas on continuous improvement in manufacturing, while the adoption of code review over the last 15 years has, in my opinion, done more to improve everyday programming than any number of books or websites.

But this kind of feedback isn't part of teaching culture in North America. Here, what happens in the classroom stays in the classroom: teachers don't watch each other's lessons on a regular basis, so they can't borrow each other's good ideas. The result is that every teacher has to invent teaching on their own. They may get lesson plans and assignments from colleagues, the school board, a textbook publisher, or the Internet, but each teacher has to figure out on their own how to combine that with the theory they've learned in ed school to deliver an actual lesson in an actual classroom for actual students.

Which is, to my embarrassment, a pretty accurate description of what Software Carpentry instructors have to do as well. The training course that I run covers the basics of educational psychology and instructional design, but doesn't walk trainees through our existing material or how to deliver it. That oversight is completely my fault, and doubly embarrassing given how many people have asked me to do precisely that.

Another thing I've realized is that there's no longer a "reference implementation" for Software Carpentry. Eighteen months ago, I had taught with almost everyone who was teaching for us. Today, that fraction is hovering around a third, and is inevitably going to continue to drop. I don't think my way is the only right way, or even the best way, but at least it was a single way that everyone used to have in common. It isn't any more, which I think is part of the reason there are growing disagreements over what to teach and how to teach it.

My third realization is that I haven't been asking instructors the right questions about our bootcamps. About half of them fill in a short survey when they're done teaching, but it doesn't ask, "How far did you get with each topic?" or, "What worked really well or really poorly?" People occasionally post unsolicited answers to these questions on the blog or discussion list, but I haven't systematically synthesized that material, which means we don't really know how our lessons are working from the instructors' point of view.

If we were all at the same university, or even in the same state or province, we could try fixing all this with some jugyokenkyu. Unfortunately, what's described in BaBT depends on frequent, time-consuming, high-bandwidth interaction, but our instructors only teach a couple of times a year as a sideline to their real work. Outside the days they're actually teaching, they're scattered across six continents, trying to catch up on all the work they pushed aside to go run a bootcamp. If we can find funding for in-person meetups, they'd be good for community-building as well as teaching improvement, but that's going to take months to arrange (at least).

So here's what I'd like to try right now. Every second week (when the instructor trainees aren't having their meeting) we will run a couple of hour-long sessions in which a couple of people who have recently taught bootcamps are invited to talk through what they did and how it went. The emphasis will be on specifics: not, "Should we be teaching principles or specific tools?" but, "The first example of how to write a function in Python left everyone cold," or, "Everybody found the early discussion of types bewildering: we should delay it or eliminate it." People who haven't taught recently (or haven't yet taught at all) would be encouraged to join in, but the aim would be to figure out where we really are and how to make things better.

Separately, we can start recording snippets of our teaching and posting them so that other instructors can learn from them and comment on them. We can do this using standard video sharing sites, or adopt something like SmarterCookie or Edthena (which I mentioned back in February). The emphasis here would be "snippets": Edthena and SmarterCookie both allow people to upload only 5-10 minutes at a time, since that's all most other people will watch. As a fringe benefit, this would also let us build up a "best of" archive. I don't think learners would be able to stitch together a complete bootcamp by watching these, but I'd be happy to be proved wrong...

Discussion sessions and video recordings will take time, though, and we're already asking for a lot of that from our instructors. As John Blischak said in a comment on the first draft of this post:

Preparing and running a bootcamp is already an exhausting and time-consuming endeavour. Then post-bootcamp we also want them to contribute back improvements to the lesson materials. Trying to schedule a meeting within a week or two after the bootcamp is just one more thing as they try to catch back up on their work.

His counter-proposal is to discuss teaching by email:

I want to increase the communication of our collective experiences. I think this could be accomplished by encouraging more discussion of teaching questions on the discuss list. This allows more people to participate in the discussion (or just read along) in a distributed fashion without committing an hour during the work day. Then the discussions that happen that month could be summarized and discussed at the weekly lab meeting.

Like John, I find asynchronous when-you-can email a lot easier to manage than scheduled meetings. After last month's kerfuffle on the mailing list, though, several people made it clear that they aren't fond of forums, IRC, and mailing lists, and would rather interact directly. Since we understand the strengths and weaknesses of the former, I'd like to give chats a try to see if they'll bring in people we otherwise wouldn't hear from. We'll take notes and post them to the mailing list and blog for those who can't attend, and hopefully some happy combination will emerge.

The first rule of engineering is "Only change one thing at a time." We keep breaking that: we keep trying to change how we teach as well as changing how scientists use computers in their research. It's a risky strategy, but, I think, a necessary one. I'd be grateful for your thoughts.