How to run a help queue in a classroom

A raised hand stops the student working: they can't type with one arm in the air, so they wait and do nothing. It also leaves the order to you, in the moment, and in the moment you go to whoever is closest, loudest or most insistent. The quiet student at the back waits longest, and is the least likely to ask again.

A queue fixes both. The student signs up and keeps working. The order is decided by when they asked, not by how hard they waved, and everyone can see that it is fair. You can also see the whole list at once, which is what lets you notice that four people are stuck on the same thing.

Any list works, as long as there is only one and everyone knows where it is:

• Names on the whiteboard, in the order students write them.
• Sticky notes: a coloured note on the laptop means "I need help". Greg Wilson recommends this over raised hands because it's discreet, so people actually use it, and they can keep working while their flag is up.
• A digital queue on the students' screens, which also keeps the order for you.

Ask for one line with each request: what's wrong, and what they already tried. "My CSS doesn't change anything, I saved and refreshed" tells you a lot before you walk over. Two notes that describe the same mistake tell you even more.

First come, first served is the right default. It's simple, it's visible, and students accept it as fair.

When the queue gets long, one change helps more students: take the ones who haven't had help yet this lesson before someone coming back for a second or third time. In a 2024 simulation of a programming course's office hours queue, putting students who hadn't been helped that day first raised the share who got help at least once from 70% to 82% on a normal day, without making the average wait longer. The authors kept first come, first served for in-person office hours, where students rarely come back the same day; in a class they come back within minutes, which is when this rule matters, so tell the room why the order changed. Wilson describes a low-tech way to do the same in a classroom: each learner puts a sticky note with their name on their laptop and takes it down once you've helped them, so you can see at a glance who you haven't reached yet.

Make one exception known in advance: a student who can't do anything at all, such as a laptop that won't start the program everyone needs, may skip ahead. A question about the next detail can wait its turn.

Every minute you spend with one student is a minute everyone else in the queue waits. Aim for a few minutes, and when a problem will take longer, leave the student with a next thing to try and come back after the next person.

• Ask them to show you what they did and what they expected.
• Don't take the keyboard. The Carpentries' handbook lists taking over a learner's keyboard among the habits to avoid: guide them through the fix and let them type it themselves, so they can do it again.
• Close the loop. Before you leave, check that it works. A student whose problem came back has to start again at the end of the queue.

Students in a queue tend to sit and wait. In a study of a programming course's online office hours, only 21% of the students waiting for help committed any code while they waited. Give the queue something to do:

• Ask a neighbour first. Many classrooms use "ask three before me": a classmate who just finished the step often fixes it faster than you can get there.
• Try the next thing. Re-read the step, compare their code with the example line by line, or move on to the next step and come back.
• Leave the request up. If they fix it themselves, they take their name off the list, and you skip one visit.

Two signals mean the queue is the wrong tool for the moment. If three requests describe the same problem, stop and explain it once to the whole room, then fix that step before you teach the lesson again. If the queue keeps growing anyway, you need more hands: The Carpentries recommend one helper for every 8 to 10 learners in their workshops. A helper takes the queue, so you can keep teaching, and watches the room for anyone stuck who hasn't asked yet (how to tell which students are stuck covers finding them).

In Workshopy the queue is built in. A student presses Need help and can add a note, such as "my code throws an error on line 3". They keep working; their screen shows that they're waiting for help, and pressing Asked takes the request back if they fix it themselves.

On your screen the student's square in the room turns amber, and the Help tab lists every request oldest first: the student's name, the step they asked on, how long they've been waiting and their note, with Go to step to open the step they asked about and Resolve when you're done. A request that has waited five minutes turns red. When requests come from more than one step, the tab counts them per step, which is how a step that is tripping up the whole class shows itself.

When you press Resolve, the student is asked whether they're still stuck and can ask again with one tap. To answer one student without the class reading it, send them a private message. After the class, the report shows how many students asked for help on each step and how long they waited for an answer.