How to Reduce Long Lines at CS Office Hours in Five Tweets

My Ph.D. student, Katie Cunningham, tweeted the possibility that we could reduce long lines at computer science (CS) class office hours with improved teaching (see tweet here). I agreed (this tweet), and received a significant and somewhat surprising response.

There are some well-supported methods that might reduce the long lines at office hours, but few people use them. Based on the latest research at SIGCSE 2019, adoption rate of these methods is likely less than 5%. I decided to write five tweets with these methods. Since a tweet is limited to only a few characters, I’m expanding on those tweets here.

I’ll admit up front that the title is a bit of click-bait. I can’t guarantee that I can reduce the long lines at office hours. I have seen these methods work. I recommend them. Of course, there may be issues in your classes that I haven’t seen or learned about from the research literature.

My suggestions here do not in any way suggest that students visiting office hours is a bad thing. Students should interact with instructors. However, I don’t believe that the long queues do anyone any good. I suggest that every student should interact with teachers and teaching assistants one-to-one (1:1) at several points in every class, but if most students need 1:1 help on most assignments or to revisit most topics, then maybe there are inefficiencies elsewhere in the system. How can we meet student learning needs without those long lines?

Here are the five tweets, with commentary:

Five Suggestions on How to Reduce Long Lines at CS Office Hours:

1. Use Peer Instruction. It is the most effective in-class teaching method I’ve ever used. If students learn more in-class, maybe they'll need less 1:1 help. https://www.peerinstruction4cs.org/

Beth Simon, Leo Porter, and Cynthia Lee taught me how to do peer instruction. They had to convince me. I blogged about my first experiences in 2011 (see example post here). It changed how I taught, and it changed me into a better teacher. I have always taught with peer instruction and other forms of active learning (like inverse live coding) ever since.

Let’s be really clear: The research supports the Peer Instruction protocol (see a nice description of it here). Hiring lots of TAs is NOT Peer Instruction (though that might be part of Peer Mentoring or Peer-Led Team Learning). Having students work in small groups is NOT Peer Instruction. There are other active learning methods in CS classes. Peer instruction in CS has the strongest research evidence in support of its effectiveness.

2. Organize and require pair programming. Students do need 1:1 help. Pair programming can lead to better learning and improved attitudes about CS. But actually organize it—form pairs, expect it. https://www.etr.org/blog/research-pair-programming/

Just saying "You can collaborate" or "I encourage Pair Programming" is not the same as (a) organizing how pairs are formed, (b) teaching how to do pair programming, and (c) expecting it in grading.

Students often do need personalized help. It doesn’t always have to come from the teacher or TA. Pair programming also has some significant positive impacts on diversity. There were so many links that I could have put in this tweet, and I struggled to decide which one to put in. The ETR link I included is a great overview. If you want a detailed explanation of how to do pair programming in the classroom, I highly recommend the NCWIT Pair Programming in a Box resources (see link here).

Pair Programming doesn’t always work. Pairs can go awry. But do the cost-benefit analysis. What percentage of pairs are ineffective, vs. how much time is wasted with students waiting in queues for office hours and what percentage of office hour 1:1 time is ineffective? In the long run, pair programming is a bigger win.

3. Backwards Design. Look at your assignments. Did you teach everything needed to do them? No, it doesn't help learning to have students "figure it out on their own." That's what leads to long lines. If you didn't teach it, don't require it in the assignment. https://thelearnersway.net/ideas/2017/11/26/inquiry-vs-direct-instruction-the-great-debate-and-how-it-went-wrong

In CS, there is a pervasive attitude summarized in four letters: RTFM (read a great post about those four letters). We tend to believe that students should learn to figure things out on their own and seek out resources to guide them. The problem is that that’s really inefficient and encourages long lines at office hours. Students would rather wait hours for a specific answer then spend hours (maybe more, maybe less) for the chance at an answer.

Here’s the point of the tweet in an even shorter form: If you didn’t teach something, don’t require students to use it in an assignment

Seriously. Direct instruction beats out students wandering around through resources trying to find an answer (see my post from last November making that same point). There is no learning benefit for making students figure it out on their own.

4. Change classroom climate. CS classes tend to have a defensive climate: Critical, impersonal, with informal student hierarchies. That discourages diversity, and discourages coming to lecture. https://www.cs.kent.ac.uk/people/staff/saf/dc/meetings/p43-barker.pdf

This last semester, I taught my first CS Education Research class at the University of Michigan (see link here). A significant percentage of my students did their research work around the idea of "Defensive Climate." Computer science classes tend to have a defensive climate, i.e., where the class is impersonal, unfriendly, often critical or combative, and there are informal student hierarchies (e.g., the students with lots of experience ask questions that other students don’t even understand). We need to teach in a way that discourages defensive climate (see NCWIT article on that). If we taught in way that was more inclusive and welcoming, students would likely come to lecture, engage, and learn more — and then might need less 1:1 teaching in office hours.

Please don’t use grade caps to limit enrollment. I make that argument here. You will very likely reduce your diversity if you do. If you have to limit enrollment, make it a lottery so that both privileged and underprivileged students have a fair shot at getting in.

5. Be explicit in your expectations that every student can learn CS. Many CS instructors believe that some students "got it" and other students can't. There's no evidence that's true, but we teach and design our classes that way. Teach to the bottom third of the distribution. https://cacm.acm.org/blogs/blog-cacm/207282-geek-gene-teacher-and-student-self-efficacy-and-the-problem-of-pythons-self-a-report-on-icer-2016/fulltext

I’ve written a lot about the Geek Gene, the belief that some students have innate ability and others do not. It’s a pervasive belief in CS education. If you believe that only some students are going to succeed, you will likely teach for their success. You will teach to the top few percent of the class. If you explicitly expect that everyone can succeed (e.g., saying in class "You can all pass this class"), and you teach to those students who have less preparation but can succeed, then they will succeed and fewer students will be waiting in the hallway for hours to get help.