Cheaper
Dictating, Pasting and Screenshotting
Prose written from memory is the slowest and least accurate way to document something, and three cheaper methods are available to anybody.
What nobody wrote down here, and what it cost
What the deploy order is
Guessed, then corrected
Four lines would have ended it
How the staging database is rebuilt
Asked seven times
The answer was four minutes long every time
two things nobody wrote down · 16 occasions it cost somebody something
Two things, sixteen occasions, and both answers were short.
For distributed teams, documentation decisions improve when time and activity are visible in context, which is why it can help to Monitask workforce insights alongside the editorial review.
A useful independent point of reference for this part of the process is Joomla.
The same four things captured by different means, with the author's minutes counted
Typed as prose from memory
55 / 168Fifty-five minutes, and two details were wrong
Terminal output pasted in with four lines of commentary
9 / 240Nine minutes; the output is the document
Dictated as a voice note and transcribed by somebody else
14 / 198Fourteen minutes of the expert, two hours of the transcriber
Six screenshots with a caption each
11 / 207Eleven minutes, and it is the page people actually use for the console
four documents · 89 minutes written · 813 minutes saved across 62 readings
Four rows, 89 minutes of author time, 775 minutes saved across 62 readings. The first row is the method everybody assumes documentation requires and is the most expensive and least accurate of the four. The other three are ways of capturing what already exists rather than composing something new. One team's own quarter.
Documenting something is usually imagined as composing prose: sitting down and writing an explanation in sentences.
That is the most expensive available method and frequently the least accurate, because it requires reconstruction. Three cheaper methods capture what is already there.
Pasting what the machine said
Terminal output, a log excerpt, a configuration file, an error message. Paste it in and add four lines of commentary.
This costs almost nothing, it is exactly accurate, and it is the thing readers most often want — a person trying to tell whether something worked wants to see what working looks like, and a description in prose is strictly worse than the actual output.
The reluctance is aesthetic: a page of pasted output does not look like a document. It is, however, the page people use.
Screenshots, where the thing is visual
For anything in a console, a dashboard or an interface, six screenshots with a caption each will beat two pages of prose at a tenth of the cost.
The caveats are real and manageable. Screenshots go stale when the interface changes, so date them. They are not searchable, so the caption carries the words. And they must not contain anything that should not be in a document — customer data, credentials, names — which requires a look before pasting rather than a policy against the method.
Dictating
For anything where the material is in somebody's head and they can explain it in ten minutes but will not write it in sixty.
Record them explaining it. Transcribe — by machine or by a colleague. Edit lightly, or publish the transcript with a note saying what it is.
This is the same division of labour as the interview method described earlier, with the recording replacing the interviewer. It is less good, because nobody is asking the obvious questions, and it is available when no second person is.
What each is good for
| Method | Good for | Weak at |
|---|---|---|
| Pasting output | Showing what success and failure look like | Explaining why |
| Screenshots | Anything in an interface | Searching, staying current |
| Dictation | Material in one head, explained easily | Structure, omissions |
| Prose from memory | Reasoning, overviews | Cost, accuracy of detail |
The last row is where most people start and it is the right choice for exactly one of the four columns.
The objection about professionalism
Pasted output and screenshots are sometimes resisted on the grounds that proper documentation is written.
Proper documentation is documentation that exists and answers the question. The alternative on offer is not a well-written page; it is nothing, because the well-written page costs fifty-five minutes that nobody has.
It is worth saying this out loud in a team once, because the unexamined standard — that a document should be composed prose — silently rules out the three cheapest methods available.
Mixing them
Most good short pages are a mixture: two sentences of context, a block of pasted output, a screenshot, one line about what to do if it fails.
That page takes twelve minutes and is better than the prose version, because the parts that are better shown are shown and only the parts that need explaining are explained.
One line that all three need
A paste, a screenshot and a transcript are all undated assertions without it, and a reader cannot judge any of them.
- "Output from the deploy on 14 March."
- "The console as it looked in March 2026."
- "Transcribed from a conversation on 2 April; lightly edited."
Ten words. With it, each becomes a dated record, which — as the page on liability argued — is the kind of document nobody has to maintain and nobody can be blamed for.
Without it, a screenshot of an interface that has since changed is actively misleading, and the misleading is attributed to whoever pasted it rather than to the passage of time.
The one rule that applies to all three
Say what the thing is and when it was captured.
"Output from the deploy on 14 March" or "the console as it looked in March". One line. Without it, a paste or a screenshot is an undated assertion, and a reader cannot tell whether it still holds.
With it, the page becomes a dated record, which — as the page on liability argued — is the kind of document nobody has to maintain and nobody can be blamed for.