My DH101 class this year was my biggest yet, with 45 undergrads. I suppose that’s not huge compared with many other classes, but DH101 is very hands-on. I am fortunate enough to have a TA, the awesome Francesca Albrezzi, who runs separate weekly labs. Still, I often have to teach students to do technical things in a large-group setting, and the size of the class this year prompted me to rethink how I do this.
As I see it, many of my students’ biggest problem with computers is their own anxiety. Obviously, I have a self-selecting group, since I teach a class with “digital” in the title, but even so, many of my students tell me that they are just “not technical.” Many of them are so convinced of this that they see any failure to get something to work as confirmation of what they already knew: they’re just not good with computers.
And since this is UCLA, the vast majority of my students do not fit the stereotype of the Silicon Valley programmer. This is awesome for the class, since we have so many different voices in the room. But it also puts many of my students at risk for stereotype threat, in which students’ performance suffers because they fear their mistakes will be seen as representative of their entire race or gender.
I’ve seen a version of this happen in workshops countless times. The instructor issues directions while students try to keep up at each step. Some students accomplish each step quickly, but some students take a little longer to find the right menu item or remember where they’ve saved a file. No matter how often you tell students to please interrupt or raise a hand if they need help, most students won’t do this. They don’t want to slow everyone else down with what they’re sure is a stupid question. Eventually, these students stop trying to follow along, and the workshop becomes, in their minds, further evidence that they’re not cut out for this.
This is how I always taught workshops, and I just couldn’t seem to get past this problem. I made and printed detailed tutorials, enlisted people to circulate and watch students’ screens, and gave speeches about the importance of patience and asking questions — all to no avail. Some people ended up bored, others (including me) frustrated.
Finally, this year, I admitted it wasn’t working and tried something else. I’d always made detailed, illustrated tutorials for my students anyway — it’s how I think through the steps students need to take (and often it’s a way for me to learn the software myself). So this time, instead of standing in front of the class and walking the students through the steps as one, I seated the students in groups and instructed each student to go through the tutorial individually.
This is simple and head-smackingly obvious, but it has a number of positive effects. First, students can work at their own pace. College students, of course, are perfectly good at entertaining themselves on computers if they finish early, so there’s not as much pressure on the slower people to work quickly. Second, students can ask each other for help as a first line of defense. Duh. Of course they like to do that. It’s so much easier to lean over and ask a tablemate what you missed than to raise your hand in front of the whole class. Third, it’s fun for them. They can laugh and joke with each other, rather than sit in silence as I repeat information that’s right in front of them anyway.
The final missing piece was Post-It notes, a strategy I borrowed from Deb Verhoeven. (Thanks, Deb!) Every student starts with a green Post-It note on her laptop. That means everything’s OK. Run into a problem that they need me for? Swap it out for red. Finished? Swap it out for white.
It might sound a little silly, but it works great. It makes students laugh and reassures them that I’m there to help. And I can, at a glance, gauge how the room is doing. When students are done, I like to ask them to get up and help anyone who puts up a red flag. That assists me, of course, but I think it also conveys to students that their job is not just to learn a skill but to contribute to an environment where everyone can succeed.
I got 45 students to make pivot tables in Excel, build websites with HTML and CSS, and build network graphs with Gephi this way. And that’s not easy, in case you didn’t know! (Next time around, I’d like to use this class formation as a setting for them to solve problems that require creativity, rather than just follow my tutorials by rote.) I’ve started using this method whenever I teach workshops and I’ve been very happy with it. Even faculty members play along with the Post-It notes, because I think they see the logic to it, too.
I would love to hear what you do to teach technical skills! I know there are many different strategies for this.