Answers · from work actually shipped
Questions this work keeps answering
Short answers to the questions behind the case studies — written from builds that shipped, not from theory. Each one links to the full writeup.
How do you train staff on a system that has no practice mode?
You build the practice mode yourself. When every action in the real system is an irreversible, timestamped submission attached to someone’s actual case, the usual fallback — watch a competent person, then do it live with them standing behind you — spreads the cost thin enough to look free while still being paid by a senior person’s afternoon and by the occasional real mistake. A high-fidelity mock of the wizard gives people a cheap place to be wrong.
How closely should a training environment copy the real system?
Not as closely as instinct suggests. Fidelity is a trap: past a point, every extra detail you copy is a detail you must maintain when the real system changes, and some divergences are worth defending on purpose. What matters more is being honest about where the model stops, so nobody mistakes a simplification for the real behaviour.
Should automation press the final submit button?
Not when the submission is irreversible. The useful question is not how much of the process the automation removes, but where in the process errors stop being recoverable — and whether the automation stops on the safe side of that line. Automating the assembly and handing a finished draft to a human keeps the system one that only has to be reviewable, rather than one that has to be right.
What does one job mean when two systems both have an id field?
It means you have a domain question wearing a data-plumbing costume. A spreadsheet export and an API can both expose something that looks like a job identifier while counting different units of work, and treating them as interchangeable produces numbers that stay plausible for a long time. The dedupe key has to follow what actually counts as one unit of work, not whichever field is named id.
Why do green test suites still let defects ship?
Because a passing suite only proves the things you thought to ask. Eight green suites still left a tab that never came back, a save that loaded cleanly and then died, and a note lost inside its own autosave window — none of which ordinary play would surface. Attacking a build from several deliberately hostile directions finds a different class of defect than writing more tests of the same kind.
Full writeup: Six defects ordinary play would never have found →
Why build internal tools local-first with no server or account?
Because most internal tools do not need a backend to justify one, and adding it buys you accounts, hosting, and an exit problem. A local-first desktop tool can ingest a messy export, resolve it into real units of work, and produce reporting someone can act on without anything leaving the machine it was created on.