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.
29 Replies to “A better way to teach technical skills to a group”
Thank for you sharing this method – it sounds great, and I’m keeping it mind for the next time I have to do some teaching like this (which doesn’t come up so often for me).
I’ve taken to referring my students to Lynda.com, a service my U subscribed to a couple years ago. It has video tutorials for all kinds of programs, and they get to learn to make charts in Excel at their own pace. And I don’t have to spend (yes, frustrated!!) class time on it. That’s also important because it’s not really a DH class, I just insist on making them use data in Excel because data are really useful.
Great ideas. And the post-it note idea can be made useful for internal assessment too. If you have a multi-part exercise, give the stages clear and obvious names, use the green/red/white post-its, and have the students write what stage they are at on green post-its. That way, you can quickly note which steps in the process produce the largest gaps in “getting it” and you can more easily recruit the students who are picking things up quickly to help those who are getting stuck. (And you can also see who is zoning out by the fact that their post-its don’t change at all)
I found this post via the Software Carpentry community, which loves the Post-It Notes technique!
When I teach technical skills I’m very much informed by Mel Chua’s summary of educational psychology for use by technical learners: http://blog.melchua.com/2013/10/07/edupsych-for-hacker-schoolers-v-1-1-presentation-slides/ One thing I try to do is allow my own mistakes to happen and then model, for the students, how to recover from them.
I’m studying history of art at LMU Munich and we have a coruse called “Software for history of Art” where we discuss programs like R Project, image plot, Excel, gephi, processing etc. This is the link to our Blog netzbild.blogspot.de (it’s in german) anyway, we are a very small group (about 5-10) so it is a little bit easier to do the workshop, gut there is always somebody struggling With the software. Most of the students in history of Art keep telling me: What is this Digital stuff good for? They think it is just a nice gadget but unnecessary for research. That’s why our classroom is not so full (yet) + as you said, they are afriad of the technical skills.
The idea with the post-its ans groups sounds really good! I’m always learning the most, When i’m practicing and talking about the topic With others 🙂
I really appreciate this post. Many thanks. (I’ll teach my first DH class next fall.)
A variation on the post-its thing I often did in mapping workshops was to put up a slide with, say, 6 easy tasks, then periodically ask the room for a “finger count” – if you’ve done three tasks, you show 3 fingers. As soon as I see 6es, I start asking them to help the 2s and 3s.
In general I did something between the “before” and “after” methods described here – describe a goal (“make your map look like this one”), give the class a few minutes to play and try to achieve the goal, and then use a combination of reporting back and straightforward teaching – “here’s what you would need to do to achieve the goal”.
The idea of letting the class run itself for longer stretches of time is interesting – wonder how you stop them getting distracted though?
FWIW, the biggest difference I noticed between humanities classes and non-humanities (eg, biomed science) is just the range in abilities. The sciences would generally be moderately (but not super) comfortable with computers, whereas humanities students would be all over the place – some low, some high. And there would usually be 1-2 people in a class of 15 humanities students whose brains just fundamentally won’t accept technical information structured in the way I was providing it. I don’t recall ever meeting people like that in the sciences.
(And of course, giving a workshop like this to actual IT-technical people was completely different.)
I teach in a school district with a 1 student:1 laptop initiative. I don’t see why this idea should be limited to tech skills. I’m going to try it out in my classroom, and thanks for the idea!
I taught technical professionals emotional intelligence skills for 12 years. After the first two years I quickly realized as you did that we all process differently based on so many factors. Some would not admit to being lost or confused.
I set up learning circles. We did informal inventories of their:
– personality styles – I found the Personality Dimensions program insightful, playful and with enough information for school, home and work that the adult students 19 – 59 all paid attention.
– learning styles
– intelligence styles
So after they inventoried themselves. They then needed to share it with a family member, a current or former coworker and another student for feedback.
Then they had to list top 7 – 12 attributes they’d learned of self and 3 attributes of self that on occasion they or others found annoying or frustrating to be around or deal with.
Over all we invested about 15 hours of classroom time However my job as the “soft skills” instructor was to help them understand self better and build team. they where on a 48 week, 30 hr a week 5 semester course.
The technical instructors feedback was that students who took this program where easier to teach and more eager to learn.
Plus the classroom dynamics where more upbeat.
Insightful article thanks for the share.
I’m going to try this for student training of our LMS software.
Great article. Bookmarking it to forward to some educators later. Will probably try it myself, too. Btw, you’ve made No 6 on a quality, news site:
I think the students would appreciate being heard. You could ask “What apps do you use?” and have them add their app to a shared spreadsheet on Google drive.
Each student gets a column, with which they type their comments about each app in column 1.
For my first two Intro-to-CS classes at USC, labs were taught in a similar way. We’d have a TA introducing the assignment and watching over the class, and a few Course Producers (basically TA’s, students a year or two older than us) circulating and helping. We would all have the assignment to do individually, but allowed to talk to neighbors and CP’s when we needed help. It worked well – when kids finished they’d often help other people, there was no competitive atmosphere.
I wish they would have used the post-it-notes though – sometimes when you got stuck you could be waiting for five or ten minutes for a CP (helping other kids) with your hand raised. That wasn’t fun.
This is a great idea, will try it soon, usually I do the first method you mention but I like the idea of giving them the tutorial and go from there, also the collaboration between the students should be fun.
Be perfectly honest, learning tech skills at a university is one of the most boring things ever.
Thanks Miriam for sharing this. Is it possible for you to share your step by step tutorials? I have been in the software development industry for a long time and have been thinking of ways to share what I have learned over all these years.
I would have loved this format for all my labs. I think it ties in a lot of good practices that are useful down the line. There are no lone wolves in the industry, software is built by teams. Sharpening communication skills and building a sense of camaraderie is key to a healthy learning environment and to building better software imo.
Thanks for the insight. Hope some of my lazy (exhausted) lab TAs read this too 🙂
I learnt somewhat by accident that I call “paired exercising” is very valuable for practical exercise sections of a training course. This was initially enforced by having too many students for a class so they had to share, but I realised that they asked many more questions- if they couldn’t work it out between them then they were much more likely to ask for help. This has similarities to paired programming of XP fame.
These days I strongly recommend it, although there are sometimes a few loners who don’t like to share, and people can be more reticent about sharing if they are not from the same company. Also, I do remind them from time to time to “play nicely” and to make sure they swap round so it is not always the same person typing.
I really appreciate this post. Many thanks.