Covering a Lecture

Sooner or later an instructor asks you to cover a lecture: they are traveling, sick, or giving you the experience. Usually you get their slides and a week's notice. It is a real chance to teach, and it can go into your teaching portfolio. It can also be nerve-wracking, especially the first time, or if English is not your first language. The good news: a covered lecture does not need to be brilliant. It needs three clear points, good timing, and a few moments where students do something. This page gives you a timeline, techniques for the room and for live coding, and what to keep afterward.

Defaults that work. If you only take four things from this page:

Ask the instructor which three things students must leave with, and cut everything that does not serve them.
Rehearse out loud with a timer, once, and know which slides you will skip if you run long.
Plan two or three moments where students answer a question, with a partner or a poll.
Ask someone to observe and give you two or three specific comments. Keep them for your portfolio.

A week before

Get the slides, and 15 minutes with the instructor. Ask: which three points must students leave with? What came last lecture, and what comes next? Is this on a homework or an exam? What can I cut? Can I change the slides?
Write the three points on one card. Cut every slide that does not serve them, and add your own example where theirs is thin. A lecture you understand in your own words goes better than someone else's slides read aloud.
Plan two or three interaction breaks. Write each question in advance, with wrong answers taken from real student mistakes.
If you will live code, write and test the code on the machine and setup you will use in the room.

Two days before

Do one full run-through out loud, with a timer, and record it. Watch it as a student would: pace, filler words, terms you stumble on. Most people find they need to cut.
Mark two or three slides you can skip if you run long. Running over is the most common problem in a covered lecture.
If English is not your first language, practice the key technical terms aloud, and put them on the slides so students can read them as you say them.

The day of

Arrive 10 to 15 minutes early. Test the projector, the microphone, the font size from the back row, and any poll you plan to use. Turn off notifications.
Open with who you are, the plan, and the three points. "Professor ___ is away today. I'm ___, one of your TAs. By the end of class you should be able to ___."
Signpost as you go: "That's the first idea. Now the second." Pause to summarize after each part.
Close with the three points again, and what comes next in the course.

In the room

Plan in blocks, not slides

Plan roughly 10 to 15 minutes of explanation, then something students do, then the next block. The famous "10-minute attention span" is not well supported by the research, so treat the breaks as good practice rather than a hard clock. They also give you a moment to catch your breath.

Get students doing something

Peer instruction. Ask a concept question, give a minute to answer alone (a poll or a show of hands), give two to four minutes to discuss with a neighbor while you walk the room, then vote again and explain. Questions work best when about a third to two thirds of students get them right at first.
Think-pair-share if you have no polling tool. Don't cut the thinking time short; students need longer than you do.
A one-minute writing prompt: "Predict the output." "What is the base case?" Then call on two or three students.
Ask specific questions. Never "Any questions?" or "Does everyone understand?". Ask "What does this return if the list is empty?"

This is worth the time. Across four CS courses at one university, sections taught with peer instruction cut fail rates by about 60% compared with standard lectures. A large review of STEM courses found active learning raised exam scores and lowered failure rates (from about 34% to 22%).

Live coding

Type, don't paste, and go slower than feels natural. Say what you are doing on every line.
Make it readable: a large font, dark text on a light background, a full-screen window, and nothing at the bottom edge where heads block the view.
Let errors happen. Read the error message aloud and debug in front of the class. Students say this is one of the most useful things about live coding.
Keep a finished version open in another file, in case you get stuck.
Keep it short. Live coding should support your three points, not take over the hour. Many instructors find it more stressful than slides, so you are not alone if it makes you nervous.

Questions you can't answer

Repeat the question (it helps everyone hear it, and buys you a moment), say what you would need to know to answer it, and promise to follow up. Then post the answer on the course forum. The When You Don't Know the Answer page has more.

Nerves and voice

Speak more slowly than feels natural, and repeat key terms.
Write hard words on the board or put them on the slide.
If the room goes silent after a question, give a partner task and walk around. Silence usually means nerves or thinking, not that you lost them.
Remember that the students want you to do well.

After

Within a day, write down what worked, what you cut and what confused students. Tell the instructor what was covered and what was not.
Ask your observer (the instructor, or another TA) for two or three specific comments.
Consider a three-question anonymous survey: what was clearest, what was least clear, and one suggestion.
Keep it for your portfolio: the slides, the observer's notes, the survey results, and a paragraph on what you would change. That is exactly the evidence a teaching portfolio asks for.