Last week, I traveled to Ann Arbor to teach a Software Carpentry bootcamp at the University of Michigan.
The workshop was hosted by a Women in Science and Engineering group, my co-instructors consisted of an all-star team: Kara Woo, Sarah Supp, and Dana Bauer. My task: teach R programming to 70 novice and intermediate students, spread across 2 rooms.
And I was scared.1
I’ve taught before. I’ve taught large groups before. I’m actually pretty competent with the R language. I can make R do lots of cool stuff. But I was scared. I’d never taught this particular material, and worse yet, I’ve never actually taught programming of any kind.2
My mind was blizzard of potential disasters. What if I screw up? What if I pace it all wrong? What if I choose the wrong material to teach? What if I don’t know what I’m talking about after all, I mean, I don’t know everything! What if all the students know more than me? And on, and on, and on.
Y’know what? It actually went pretty well. And furthermore, I *like* teaching coding.
The material I delivered to both groups was very similar. I talked a bit about motivations for using R, and scripted analyses in general, walked them through the R Studio interface, then into data importation and object manipulation. I went a bit slower in this section for the novice group, and used the Data Carpentry materials for object manipulation for them, but just the standard Software Carpentry materials for the intermediate group. I taught Functions and Loops in detail to the intermediate group, and a little more superficially to the novice group. Both lessons ended with having the students write a function which automated the analysis process for several similar datasets (which, believe me, makes you feel very powerful).
There were two big elements- two pedagogical techniques- that were big, big contributors to the success3 of the lessons: Live coding and the sticky note technique. These techniques are emphasized so much during our training, and being on the other side, I can see why.
Live coding is a technique that seems really intimidating at first, but it helped me so much to both pace my lesson and articulate my thinking to the students. Simply: you don’t use the now-traditional teaching tool of a Powerpoint to project the code you want the students to learn, with outputs already preformed, up on a screen. What my fellow instructors and I have learned to do is have a laptop for the purpose of live coding, and then have lesson materials handy on a separate device like a tablet computer. You project your coding environment (in this case, R Studio) from the laptop, and you type the commands, by hand, as cued by your lesson materials on your tablet. And then you run the code live. The purpose of this is threefold- first, manually typing in each command gives you the opportunity to explain what each piece of code means, in real time. Secondly, it helps with pacing. Typing the commands slows you down, so you can’t deliver it much faster than the students can absorb it. Thirdly, and this is important: it allows the students to see you screw up. You’re going to make mistakes, and this is good, because 1) the students will be able to see you as a human4 and 2) bugs and typos are opportunities for your students to work with you to fix the code, improving their understanding.
We used the ‘sticky note’ technique to help break down the barriers of students not socialized to ask for help, and foster co-operative learning. This technique promotes inclusivity by lowering a student’s threshold for asking questions or signaling confusion: each student is issued one blue/green, and one red/pink sticky note. When working on a problem in class, students will signal they’ve completed the problem or their problem solving is going well by displaying the blue note, if they’re struggling, they are asked to display the red note. This enables the instructor to very quickly intervene and offer support to the students that are struggling, assess the proportion of students that are struggling, and identify key points that may have been overlooked in the lesson in real time. Frankly, it’s the most brilliant low tech technique to get real-time feedback. It also provides a slight social pressure for students who are struggling (no one want to be the one student not displaying *any* sticky note, right?) to engage and follow along while help is available. It also promotes co-operative learning- often, peers noting that a neighbor is struggling will rush in to help- which takes some of the load off the instructor while re-enforcing what the helper-student has learned.
I also probably should not underestimate the influence of various cultural elements in contributing to the success of this workshop. Software Carpentry seeks to create an inclusive environment, and so the whole culture of the organization is “We are in this together, let’s all help each other improve our skills.” It’s nice. The last time I was immersed in a more computational/quantitative environment, it was not…as supportive.5 Our attendees were self-selected: the workshop itself wasn’t on anyone’s course requirements, so it was only attended by people genuinely interested in learning what we were teaching. The WiSE aspect was very refreshing- as computational skills are a traditionally male-dominated domain, having two rooms of people who don’t ‘look like’ society’s archetypal programmer, working together, helping each other make programming work, the whole thing felt very empowering. I know I’d probably have gotten back into programming a lot earlier if I’d felt this sense of community with my fellow learners.
1 My spouse suggested titling this post “How Software Carpentry ruined Christmas” because the bootcamp was scheduled the first two days back after semester break, and I was SO NERVOUS through all of the family festivities and the only thing that could relax me was pouring over my teaching materials. I had a doctor’s appointment the afternoon the workshop ended (I am super pregnant right now), and they were concerned enough about my basically pure adrenaline state that they sent me for a pile of rather awkward tests (everything’s fine, but man, those tests were awkward). So, yeah, there’s a window into my psyche.
2 Most of the courses I’ve taught before have been ‘fact based’ as opposed to ‘skills based.’ Even with the Data Carpentry bootcamp I taught last July, I taught data management in spreadsheets, which leans a bit more fact based- “If you use ambiguous nulls, you’re going to have a bad time.” IS A FACT.
3 Where success is defined as no one, to my knowledge, including me, running out to the bathroom to cry out big salty tears of soul-destroying pain, at any point during any of the lessons.
4 The whole point of this blog is humanizing data science. I like to think that it’s working. Quantitative ecologists! They’re just like us! (Don’t you wish Science did this? Next up, EO Wilson eating a bagel!)
5 I majored in physics as an undergrad, and, while #notallmen, I was up to my armpits in “that guy”s in all my classes. I’ll never forget the time that I asked a question about citing other people’s code in my undergrad Java programming class and I got the most condescending mansplanation from a classmate about how I shouldn’t copy other people’s work….Yep. It made me want to crawl into the floor. Not what I was asking, but thanks, bro.