Explain Code on Camera Without a Screen Recording
Published · Updated · Jakub Kuźnicki
Update policy: product facts, cited sources, and checked output evidence are revalidated when they change. See the author methodology.
Explaining code on camera has two costs, not one
"Just record your screen and talk over it" sounds like the obvious way to explain a function, until you're the one setting it up: a screen recorder or a webcam, a quiet room, a script you don't stumble over, and an editor to trim the parts where you re-explained yourself. I tried a different path for a small TypeScript helper: paste it into Scribe and let the export be the explanation, with no camera and no capture software involved.
The fixture: a small debounce helper
function debounce(fn: (...args: string[]) => void, waitMs: number) {
let timer: ReturnType<typeof setTimeout> | undefined;
return (...args: string[]) => {
clearTimeout(timer);
timer = setTimeout(() => fn(...args), waitMs);
};
}This is a seven-line debounce function: a closure holding a timer, a returned function that clears and resets it. Nothing in the fixture is contrived to look good on camera, it's the same helper you'd actually paste into a utilities file. The TypeScript-specific parts, the typed parameter and the ReturnType<typeof setTimeout> annotation, draw as ordinary text; Scribe doesn't need special handling for them beyond picking TypeScript from the language list.
What this replaces, and what it doesn't
This replaces the camera and the capture software, not the explaining. You still decide what order to reveal the lines in, still choose which line to linger on, still write the words a viewer reads or hears alongside it, Scribe doesn't currently attach narration audio of its own. What disappears is the setup cost: no webcam lighting, no "can you hear me" check, no editing out a stumbled sentence, because there's no take to re-record, only text you can rewrite and re-export instantly.
Where this fits, and where a screen recording still wins
- A single function or a short snippet, explained in isolation: a drawn walkthrough keeps the frame tight around exactly the code that matters.
- A repeatable explanation you'll want to update later: editing the text and re-exporting is faster than re-recording a whole take.
- A live debugging session, a running UI, or anything where the audience needs to see program behavior over time: that's still a screen recording's job, not a paste-and-draw tool's.
The honest boundary is what's on screen. If the point is the code itself, a drawn walkthrough can carry it end to end. If the point is what the code does when it runs, a Scribe export is not a substitute for actually running it and showing that.
Try it on your own snippet
Paste any function into Scribe and preview it before deciding whether it's worth an export; preview is free and needs no account. The developer notes page has the rest of the workflow, and pricing covers what a signed-in FREE export includes versus Premium.
For the broader question of when a video communicates a change better than text at all, see code walkthrough vs. screen recording; for the same paste-and-export path applied to a pull request diff, read turn a git diff into a hand-drawn walkthrough video.