To make a video explaining your code for a class submission, do not scroll through your files top to bottom. Explain four things in order: what the program does, how its main data structure is organised, why you made the key design choice, and how you know it works. Draw the data structure and how it changes during one operation, show only the five to fifteen lines of code that matter, state the time and space complexity with a reason, then show your tests passing. Three to five minutes is enough for most assignments, which is 450 to 750 words of narration at 150 spoken words a minute. Write that script before you record anything.

What the marker is actually checking

A code walkthrough exists because the marker cannot tell from the repository alone whether you understand what you submitted. That is the whole point of it, and it changes what a good video looks like.

Most rubrics for these videos, whether for a first-year programming course or a data structures module, reward roughly the same things:

Notice that line-by-line narration of the code is not on the list. Markers can read code. What they cannot read is your reasoning, so the video should be mostly reasoning.

Draw the structure, show the code sparingly

The single most useful thing you can put on screen is a picture of your data structure changing during one operation. Code tells the marker what you wrote. The picture tells them you know what it does at runtime.

That suggests a split. Use drawn scenes for the structure and the walkthrough of one operation, and use a short screen capture or a code snippet for the lines that implement it. If you are explaining an algorithm in general rather than your own implementation, how to make a video explaining a computer science algorithm goes deeper on tracing inputs step by step.

Keep code on screen small. Five to fifteen lines at a time, large enough to read on a laptop, with the line you are talking about highlighted or pointed at. If the marker has to pause to read, you have shown too much.

Check the brief before you choose. Some courses require a screen recording of your actual IDE and terminal, because they want proof the code runs on your machine. In that case the drawn scenes are the explanation and the screen recording is the evidence, and you can cut them together in any basic video editor. If the brief only says "explain your code", a drawn walkthrough with snippets is usually fine.

Worked example: an LRU cache for a data structures assignment

Here is a typical assignment. Implement a least recently used (LRU) cache with a fixed capacity, where get(key) and put(key, value) both run in O(1) time. When the cache is full, put evicts the least recently used entry.

The standard solution combines a hash map from keys to nodes with a doubly linked list ordered by recency. The most recently used node sits at the head, the least recently used at the tail.

Scene list for a four-minute video, about 600 words of narration:

1. The problem. A box labelled "cache, capacity 3" and three slots. Narration: "This cache holds three items. When it is full and a new item arrives, it throws out the one we used longest ago. Both get and put have to be constant time."
2. Why not just a list. A plain list of keys, with an arrow scanning along it. "A list keeps the order, but finding a key means scanning it, which is O(n). A hash map finds keys in O(1) on average but forgets the order. I used both."
3. The structure. A hash map on the left with arrows pointing into a doubly linked list on the right, head and tail sentinels drawn as empty nodes. "The map points straight at a node. The list keeps the order. The sentinels mean I never have to check for an empty list."
4. Trace get(2). Cache holds 1, 2, 3 with 3 most recent. Node 2 is unlinked and moved to the head. "Getting key 2 looks it up in the map, unlinks its node, and moves it to the front. Six pointer changes, no scanning."
5. Trace put(4) when full. Node 1 at the tail is removed from both the list and the map, node 4 is inserted at the head. "The tail is always the least recently used item, so eviction is one pointer read."
6. The code. Twelve lines: the get method and the two helpers it calls, _remove(node) and _add_to_front(node). Narration walks through the helpers, not every line.
7. Complexity. "Get and put are O(1) on average, because the map lookup is average O(1) and the list changes are a fixed number of pointer updates. Space is O(capacity)."
8. Tests. A short list on screen: get on a missing key, put on an existing key updates its value and recency, capacity 1, eviction order after mixed gets and puts. Then the passing test output.
9. What I would change. "My version is not thread safe. With more time I would add a lock around put."

Scene 2 is the one students skip and markers like most. Saying what you rejected and why is the clearest proof you made a design decision rather than copied one.

Scene 9 is optional but cheap. Naming one honest limitation reads as understanding, not weakness.

Writing the script

Write the narration as prose, one paragraph per scene, before you touch any recording software. A few rules that save time:

Say the input out loud. "Cache holds 1, 2 and 3, with 3 most recent" is followable. "The cache has some items" is not.

Use the names from your code. If your helper is _add_to_front, call it that in the narration, so the marker can find it in the repository.

Give every Big O a reason. "O(1) because it is a hash lookup plus a fixed number of pointer changes" is worth marks. "O(1)" alone is a guess as far as the marker can tell.

Read it aloud with a timer. At 150 words a minute, a five-minute limit is 750 words. Most first drafts are 30 percent over.

For a wider guide to writing narration that people can follow by ear, see how to script an educational video.

Make it

1. 1

   Write the four-part outline

   What it does, how the structure is organised, why you chose it, how you tested it. If any part is empty, fix the code or the tests first.

2. 2

   Pick one operation to trace

   Choose the operation that shows the design best, usually the hardest one, and write down the exact starting state and input you will trace.

3. 3

   Write the narration

   One paragraph per scene, using your real function names, with a reason after every complexity claim. Read it aloud and cut it to the time limit.

4. 4

   Draft the drawn scenes

   Paste the script into openCanviz with Keep my wording on, so the narration is exactly what you wrote. Whiteboard style suits boxes, arrows and pointers. Check every arrow and label against your code.

5. 5

   Add the code and test evidence

   Take short screen captures or snippets of the key method and the passing tests. If the brief requires a live IDE recording, cut those clips in alongside the drawn scenes.

6. 6

   Watch it once as the marker

   Start to finish without pausing. Anything you would have to pause to read is too small or too long.

Academic honesty with code videos

Code walkthroughs are increasingly used as an integrity check, so treat them that way. If you cannot explain a line, the video is where that shows, and some courses follow up with a live viva.

The safe position under most policies: the code and the reasoning are yours, and a tool helps you draw and narrate an explanation you wrote. Check your course's rules on AI assistance for both the code and the video, and declare tool use if asked. Keep your script, because it shows the explanation existed before the video did. How to make a video for a school project covers the general rules in more detail.

Common questions

Should I show my face? Only if the brief asks. Most code walkthroughs are judged on the explanation, and the screen should be showing the structure or the code, not you.

Can I use a generated voice? Usually, but check. Some instructors want your voice as evidence that you did the explaining. If so, record your own narration over the drafted scenes using the script you wrote.

How much code should appear on screen in total? For a four-minute video, two or three snippets of five to fifteen lines each is plenty. The full code is in your submission.

What if my assignment has several files or classes? Open with a single diagram of how the classes or modules connect, one box each, then spend the rest of the video on the one or two that hold the interesting logic.

My code has a known bug. Should I mention it? Yes. Say what the bug is, which test shows it, and what you think causes it. Markers usually give more credit for an accurate diagnosis than for hiding it.