Code walkthrough vs. screen recording: show the decision, not the desktop
Published · Updated · Jakub Kuźnicki
First-party workflow note: this comparison uses Todrawn's Scribe controls and the checked deterministic fixture export linked below; it is not a customer case study.
Update policy: product facts, cited sources, and checked output evidence are revalidated when they change.
The short answer: record the decision you want remembered
A screen recording shows the whole desktop: tabs, cursor travel, editor chrome and the moment the author finds the right line. A code walkthrough can show the smaller thing a reader needs to remember: which branch runs, what it returns and why the next call follows. Neither format is universally better. The choice depends on whether the viewer needs the environment or the reasoning. For this note I used the same six-line fixture in both mental models, then checked the workflow against Scribe's source controls. The checked output below is this fixture rendered at 1920×1080 and 24 fps; it is not a benchmark. You can paste the input into Scribe and make that decision with your own code.
The input: one branch, one call site
The fixture is deliberately ordinary. It normalizes an optional path, then calls the helper once. That gives the explanation one visible turn instead of pretending a tiny snippet proves how every repository should be taught.
function choosePath(path?: string) {
if (!path) return "/";
return path.startsWith("/") ? path : `/${path}`;
}
choosePath("docs");For the source review, the workflow was paste, choose the TypeScript profile, preview and replay. The same input is what anchors the comparison; there is no stock animation hidden behind the prose.
What the screen recording keeps
- The surrounding editor, terminal or browser context when the environment is part of the lesson.
- A real cursor path when locating a file or reproducing a visible bug matters.
- The awkward parts of a live operation, if the audience must repeat that operation exactly.
That context is useful, but it also asks the viewer to filter. A recording can make a three-line decision feel like a tour of the author's machine. If the desktop is not part of the lesson, crop it out in the script before you press record.
What a walkthrough makes legible
A walkthrough lets you split the explanation at the decision: first the empty path becomes the root, then a path without a leading slash gets one, then the call site supplies the concrete input. Scribe's line-by-line playback is useful for that structure because the viewer sees the order you chose rather than a cursor wandering across a desktop. The features page describes the developer surface without turning this one fixture into a benchmark.
Before exporting, keep the source readable, remove unrelated lines and decide whether a wide frame or vertical frame suits the place the clip will live. Pricing explains the export allowance; previewing remains the low-friction way to test whether the explanation reads at all.
A practical decision rule
- Use a screen recording when the environment is evidence: a setup, a reproduction or a visible interaction.
- Use a walkthrough when the viewer needs a branch, sequence or relationship to stay in memory.
- Use both only when the second format adds context instead of repeating the first.
The honest test is not which format looks more polished. Ask what a viewer should be able to explain ten minutes later. If the answer is ‘where I clicked’, keep the desktop. If it is ‘why this branch runs’, make the reasoning the frame.
Evidence and the boundary of this note
The fixture, workflow, checked output and source observations are recorded in the first-party evidence manifest. The clip is one controlled example, not a claim about every repository, browser or viewer outcome. For a related first-hand example with a checked clip, read Explain your code in 60 seconds.
Try the workflow in Scribe, read the developer features, check pricing, or continue with the checked code explainer.