Teaching programming online: running a live coding class

Teaching programming in a room is hard. Teaching it over a video call is hard in a different way, and the difference is not delivery — you can explain a concept perfectly well through a webcam. The difference is that you have lost the ability to see who is lost.

In a classroom you read the room continuously without trying: the frown, the person who has stopped typing, the two students quietly helping each other. Online, twenty faces in a grid tell you almost nothing, and half of them have cameras off. Everything below is a substitute for that missing channel.

Why a screen share loses the class

The default setup is an instructor sharing their editor while students watch. It fails for reasons worth naming precisely.

Watching someone type is passive, and passive attention over video decays fast — considerably faster than in a room, because there is no social cost to disengaging and a browser tab is one keystroke away. A student who loses the thread at minute eight has no way back in; the code on screen has moved on, they cannot scroll back, and asking means interrupting everyone.

And the instructor gets no signal at all. You can talk confidently to a muted grid for forty minutes with no idea that a third of the class stopped following near the start. In a room that is obvious within seconds.

The fix is structural rather than stylistic: students must be typing, in something you can see. Everything else follows from that.

Give everyone a workspace you can open

The setup that works is one shared editor per student or per small group, at URLs you can open yourself.

Name them predictably before the session — /class-ana, /class-ben, or /week3-group1 through /week3-group4 — and post the list. Then you can move between them the way you would walk between desks, and see live what each person has written, without asking anyone to share anything.

This single change restores most of what remote teaching loses. You can see who has not started, who is stuck on line four, and who wrote something interesting worth showing the class. You can drop a hint directly into a student’s file rather than describing it out loud. And because you can see cursors moving, you can tell the difference between someone thinking and someone gone — which is exactly the signal the camera grid destroyed.

The requirement this puts on the tool is that opening a workspace must take no account and no install. A class of thirty cannot spend the first ten minutes signing up, and any student who fails at that step is lost for the whole session.

Structure: short cycles, not long demonstrations

The unit that works online is roughly ten minutes long and has three parts.

1. Explain and demonstrate (3–5 minutes). One concept. Written live, with mistakes left in — watching you notice and fix a typo is more instructive than watching flawless code appear, because it models what programming actually looks like.
2. They do it (4–6 minutes). A small variation on what you just showed, in their own workspace. Not a creative extension — a variation. This is practice, not assessment.
3. Regroup (1–2 minutes). Show one student’s solution (with permission), or a common mistake, or just answer what came up.

Nobody can disengage for more than five minutes without it becoming apparent, to you and to them. Compare with a forty-minute demonstration, where disengagement is invisible and irreversible.

The most common instructor error here is making the exercise too big. Online, an exercise you estimate at five minutes will take twelve, and a student who does not finish in the allotted time frequently concludes they are behind and stops. Make them smaller than feels right.

Reading a room you cannot see

Concrete substitutes for the signals you have lost.

Watch the workspaces, not the faces. Keep the student workspace list open and cycle through during exercises. Empty files two minutes in are your cue to intervene.

Ask for typed answers, not verbal ones. “Any questions?” into a video call produces silence regardless of comprehension, because speaking up means interrupting twenty people. Asking everyone to type a one-line answer into their workspace produces twenty responses and takes thirty seconds to scan.

Use the chat as a real channel. Students who will never unmute will type. Assign someone to watch it if you cannot, or check it at every regroup.

Ask specific, answerable questions. “What does line 3 print?” gets answers. “Does everyone understand closures?” gets nothing, because nobody wants to be the one who says no.

Name the silence. Saying “I can’t see your faces, so I’m going to be asking a lot of direct questions — it’s not a test” resets expectations, and makes the interruptions feel like the format rather than an interrogation.

Group work that actually works

Breakout rooms have a reputation for producing silence, and mostly deserve it. Two things fix it.

Give each group a shared workspace, not just a call. A group with a voice channel and nothing to work on together will talk about nothing. A group with a document that all of them can edit has an obvious thing to do.

Assign roles. Unstructured groups default to one person working and the rest watching, which is the passenger problem with more passengers. Rotating a driver on a timer, or ping-pong for pairs, removes the ambiguity about whose turn it is.

You can then drop into any group’s workspace to check progress without joining the call and derailing the conversation, which is a genuinely better version of walking past a table.

Details that matter more online

• Increase your font size well past comfortable. Students are on laptops, some on phones. If it looks slightly absurd on your monitor it is probably right.
• Type slower than you would alone, and say what you are typing while you type it. Fluent muscle memory is illegible to a beginner.
• Leave the code up. Workspaces that persist after the session let students go back over what happened, which is the online equivalent of not wiping the whiteboard.
• Never delete a mistake silently. Say what went wrong and why before fixing it. Error messages are content, and beginners need to be taught to read them rather than fear them.
• Post the starter code in advance, already in each workspace. Time spent copying boilerplate is time not spent learning, and it fails unevenly across the class.