Computing Profession BLOG@CACM

Cutting the Wait For CS Advice

The Communications Web site,, features more than a dozen bloggers in the BLOG@CACM community. In each issue of Communications, we'll publish selected posts or excerpts.

Follow us on Twitter at

Mark Guzdial suggests ways to cut the long lines for college students seeking to meet with their computer science advisors.
  1. Mark Guzdial: How to Reduce Long Lines at CS Office Hours in Five Tweets
  2. Author
Mark Guzdial

May 2, 2019

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 I agreed (, 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 (, the adoption rate of these methods is likely less than 5%. I decided to write five tweets with these methods (which you can see at Since a tweet is limited to only a few characters, I am 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 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:

  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.
      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 at 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 at Hiring lots of teaching assistants 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.
      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 need personalized help. It doesn’t always have to come from the teacher or teaching assistant. 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 (at
      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. Backward 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.
      In CS, there is a pervasive attitude summarized in four letters: RTFM (read a great post about those four letters at We tend to believe students should learn to figure things out on their own and seek out resources to guide them. The problem is that it’s really inefficient and encourages long lines at office hours. Students would rather wait hours for a specific answer than 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 at 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 lectures.
      This last semester, I taught my first CS Education Research class at the University of Michigan ( 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; that is, the class is impersonal, unfriendly, often critical or combative, and there are informal student hierarchies (for example, 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 at If we taught in a way that was more inclusive and welcoming, it might lead to students coming to lectures, engaging, and learning more—and they might need less 1:1 teaching in office hours.
      Please don’t use grade caps to limit enrollment. I make that argument at 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.
      I have 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 (that is, 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.

Back to Top

Join the Discussion (0)

Become a Member or Sign In to Post a Comment

The Latest from CACM

Shape the Future of Computing

ACM encourages its members to take a direct hand in shaping the future of the association. There are more ways than ever to get involved.

Get Involved

Communications of the ACM (CACM) is now a fully Open Access publication.

By opening CACM to the world, we hope to increase engagement among the broader computer science community and encourage non-members to discover the rich resources ACM has to offer.

Learn More