Teaching Librarians Programming
My experience helping out at a Software Carpentry boot camp
August 2013 (perspective of a postdoc)
I describe how I helped teach basic programming to librarians at a Software Carpentry boot camp. My observations should generalize to other settings where veteran programmers are teaching absolute beginners.
Over a two-day period in August 2013, I volunteered as a helper at a Software Carpentry boot camp for librarians at Harvard University. The purpose of this event was “to help librarians and graduate students become more productive by teaching them basic computing skills like program design, version control, testing, and task automation.”
As a helper, my job was to walk up to students who request help and get them unstuck as they work on computer-based exercises. When I wasn't helping students, I walked around the room and observed the instructors, students, and their interactions with one another.
Since I'm passionate about teaching programming and doing research on educational technology, I was fascinated by what I saw and scribbled down over thirty pages of field notes. My observations inspired some new research project ideas, which I hope to develop in the coming years. In the meantime, I've distilled my teaching-related observations into this article.
Over two days, four instructors took turns teaching the basics of:
Most lectures consisted of the instructor typing shell commands or Python code into an interactive terminal and having students follow along on their own laptops:
When an instructor was lecturing, the other three instructors, along with two helpers, stood around the room and assisted students who raised their hands. Here's a helper standing in the background beside the students:
Demographics: All four instructors were professional programmers who volunteered to teach. The 35 students were librarians and university staff with little to no prior programming experience. Over 2/3 of the students were female, and most were in their 30s, 40s, and 50s. They came both out of curiosity and to learn potentially useful job skills. These demographics are very different than a university CS course, in which the majority of students are 20-year-old males aiming to earn a diploma.
What worked well
Everyone genuinely cared: The head organizer, Chris Erdmann, gave impassioned introductory and concluding remarks about how programming would benefit this audience of librarians in particular. From talking with Chris, I could tell that he was really passionate about the greater cause of data scientist training for librarians. Also, the volunteer instructors and helpers were all very eager to help and patient with students. Overall, I got the sense that the students felt comfortable and welcome in this learning environment.
Peer learning: Many students came to class with one or two friends. Since they sat next to one another, they could easily help each other out in the middle of lecture. Even during breaks and lunchtime, I often saw students working with one another to understand concepts and run commands together on the shell:
On the flip side, although I loved seeing so many instances of peer learning, I'm a bit concerned that they sometimes share novice misconceptions with one another—incorrect explanations that happen to work well at the moment. However, it seemed too intrusive to swoop in and interrupt student explanations, so I held back unless someone explicitly asked for help.
Fast help times: The student-to-instructor ratio was 7:1, so students received help very quickly after raising their hands. Also, students would often help their neighbors, which further reduced the load on instructors. The photo below shows an instructor helping a student on the left, and students helping one another on the right:
Frequent status checks: The most effective instructors paused every five minutes or so and asked the class, “Raise your hand if you don't see what I currently see in my terminal.” Those checkpoints were great times for helpers to get students caught up before the instructor continued to the next part of the lesson. Without such status checks, once a student falls too far behind, they usually stop typing on their laptops and tune out for the rest of the lesson.
Show, don't tell: The most effective responses to student questions were those that instructors answered by running commands in the shell rather than just offering a verbal explanation. For example, student: “What does X do?”; instructor: “Let's run a few commands to find out!” Sometimes instructors engaged students more directly, which worked even better: “Let's run this command, but before I hit Enter, what do you think it will do?”
What could be improved
Lack of diagrams: Most of the concepts taught in the course—ranging from directory hierarchies to Python list indexing to Git workflow—would have been much clearer if instructors had drawn the appropriate diagrams on a whiteboard instead of simply typing in commands into a terminal. Unfortunately, the only whiteboard in the room was obscured by the projector screen, so there was no easy way to draw diagrams. A portable whiteboard beside the podium would've solved this problem.
Jargon overload: Instructors threw way too much command-line and programming jargon at students without providing enough time to let them practice, repeat, and internalize. Since instructors were veteran programmers, they “speak geek” as their native tongue and don't even realize how incredibly jargon-filled their sentences are.
For instance, when a student asked, “Why do you put a colon after a Python 'if' statement?”, an instructor replied reflexively, “Because it starts a new block.” He later explained what a block was in this context, but that question could've been answered without introducing a new piece of jargon.
Of course, jargon is often unavoidable, but one way to avoid frying students' brains is to write every new piece of jargon introduced during lecture on the whiteboard. That way, students have a visual cue of the new “vocabulary” they've learned so far. A more extreme policy is to limit the number of new pieces of jargon introduced per hour (say, 10 per hour), which forces instructors to speak more in plain English.
Blisteringly fast pace: Even though instructors knew they were teaching absolute beginners, the pace of their lessons was still way too fast for most students.
The most common manifestation of this problem was that instructors typed much faster than students, often using invisible keyboard shortcuts to make the cursor dance around the screen. Most students were fairly slow typists; many had to look at the keyboard and hunt-and-peck one key at a time. Also, since students were mostly typing jargon rather than English words—'grep', 'mkdir', 'git'—they made lots of typos, which led to frustrating errors and caused them to fall behind even more.
A simple solution is for the instructor to type using only one finger at a time without any keyboard shortcuts. That should slow down the lecture to a manageable pace.
Geek tangents: Sometimes instructors would go off on tangents during lecture to mention topics or UNIX trivia that they find interesting but are otherwise irrelevant to the lesson. I noticed students growing bored and even a bit frustrated by these asides, since they were bombarded with even more jargon as they tried to assimilate existing jargon into their minds. For example, one instructor was explaining directory hierarchies and decided on a whim to explain the significance of top-level UNIX directories like '/bin', '/dev', and '/etc', which made for great geek trivia but had no relevance to the lesson. One solution is to avoid all tangents, which reduces unnecessary cognitive load.
Multiple talking instructors: For the most part, helpers and other instructors refrained from interrupting the one who was lecturing, but sometimes they couldn't resist jumping in:
In general, when multiple instructors talked, they usually went off on geek tangents that derailed the lesson and introduced even more jargon: “I use X as my IDE because it has feature Y,” or “Some people like using Vim over ssh.” Although these exchanges might have been fun for instructors, students often looked bored or disconnected. One solution is to limit interruptions only to urgent clarifications and to calling the instructor's attention to student questions.
This was my first time attending a Software Carpentry boot camp, and I really enjoyed my experience. I highly recommend for anyone who is interested in teaching programming to volunteer as a helper at a future boot camp in your area. Doing so will allow you to both develop more empathy for the struggles of beginners and to see what makes for effective instruction.
Keep this website up and running by making a small donation.
Last modified: 2013-08-25