You are leaving a project in two days and have two hours to document the system. What do you write and what do you deliberately leave out?

What is being tested

Editorial judgement. Anyone can list documentation artefacts; the skill is knowing which ones survive contact with reality and which are stale before they are read.

What to write

1. A context diagram (15 minutes). The system, its users, and every external thing it talks to, with the direction of each dependency. This is almost never wrong and almost always the first thing a newcomer needs. Include what happens when each external dependency is unavailable — even one line each.

2. The decisions and their reasoning (45 minutes). Six to ten short records: what was decided, what the alternatives were, why they were rejected, and what the decision costs. The rejected alternatives are the valuable half. Without them, the next person re-opens every settled question and often re-makes a mistake that was already discovered and avoided.

This is the same instinct behind the design-document culture at Google, where the non-goals and alternatives considered sections do most of the work: they prevent both scope creep and the later accusation that something was overlooked.

3. The invariants (20 minutes). The things that must remain true and are not obvious from the code: "job IDs must be globally unique because the downstream system deduplicates on them", "this table must never be updated in place because the audit export reads it as an append-only log", "the third retry is deliberate — the payment provider's timeout is 30 seconds". These are what the next person will otherwise break in their second week, and they exist nowhere else.

4. The operational reality (20 minutes). What pages, what it means, what you actually do about it, and which alert is known-noisy and why it has not been fixed. Plus the runbook you have in your head for the two failures that have actually happened.

5. The known problems (20 minutes). The shortcuts, the thing that will break at 3x traffic, the dependency that is deprecated, the test that is skipped. Written down honestly, this is the most generous thing you can leave behind — and the most likely to be omitted, because it is unflattering.

What to leave out

• Anything the code says more accurately: class diagrams, endpoint lists, configuration keys.
• Anything that will be stale in a month: current instance counts, current traffic figures, the present state of a migration.
• A full component inventory. It will be wrong within a quarter and it teaches nothing.
• Setup instructions, unless they are genuinely undocumented — the README should carry those.

The framing that makes this easy

Write for the person who will be woken at 3am in four months, not for an audit. That reader needs to know what the system talks to, what breaks, what must stay true, and why it is like this. They do not need a catalogue.