I keep a short list in my notes app and reread it before a new project, client, or commitment. Each item records a mistake I would rather not pay for again.
- Problem
- Have I watched the actual workflow?
- The requested thing may miss the useful thing.
- Evidence
- What test would change my mind?
- A test, walkthrough, metric, or example can settle what certainty cannot.
- Attachment
- What would I delete if I joined today?
- Past effort does not have to make the next decision.
- Measurement
- What is measured, estimated, or only believed?
- Say where the evidence ends.
- Durability
- Will the boring version hold?
- The useful system can disappear into the work.
- Schedule
- What will I keep showing up for?
- Accumulation depends on returning, even without inspiration.
Evidence can loosen attachment. Measurement puts a boundary around evidence. A schedule gives durability time to emerge.
Put a project through the six questions
Choose any question. Follow its connections, inspect what would count as evidence, and mark where your current answer stands.
Have I watched the actual workflow?
A walkthrough with the person doing the work, including where they pause, copy, improvise, or ask for help.
Watch one task from beginning to end. Write down where the requested feature stops matching the work.
A workflow observation gives your proposed solution something real to be tested against.
The useful system must survive the actual workflow, including its recurring exceptions.
These are connected questions, not a readiness score or a required sequence. Marks describe your own assessment. Notes stay in this page’s memory and are not saved. Copy anything you want to keep before leaving or reloading.
Solve the right problem before writing a single line of code. Several projects I regret delivered the requested feature without improving the workflow. I now treat the initial problem statement as a hypothesis and ask to see the work before accepting it as a specification.
Decide with evidence, not opinions. Earlier this year I was sure about an architecture, and a colleague was sure about the opposite, and we did the thing teams do: we argued. The argument produced nothing for a week. Fifty test cases produced an answer in two days. I've stopped trusting my certainty as an input; it's a feeling, not a measurement. When two smart people disagree for more than a day, the cheapest path forward is almost never more discussion. It's a test.
Be comfortable deleting your own work. I have deleted months of work after evidence showed that the first design was wrong. Defending the implementation would have cost more than replacing it, even when the replacement felt wasteful at first.
Prefer work that stays quiet in production. I have a weakness for elegant designs that demand continuing attention. A system that handles its known failures and can be operated by the client's team is usually the better result.
Say what you didn't measure. The habit I'm most deliberate about: stating the boundary of what I actually know. "That number is an estimate, not a measurement." "This worked in our setting; I haven't tested yours." It feels like weakening your case. In practice it's the only thing that makes the rest of your case believable, and it's the difference between a reputation that compounds and one that needs constant maintenance.
Show up on a schedule, not on inspiration. Before my Master's, I spent close to four years teaching at shelter homes on Saturdays. Nothing about any single Saturday was remarkable, and that was the entire point: the value was in the accumulation, which only existed because the schedule didn't negotiate with my mood. Everything durable I've built since, skills, trust, this writing habit, has worked the same way. Inspiration is a lovely visitor and a terrible employer.
- The Checklist ManifestoGawande shows why experienced people still use short written checks when the work becomes too complex to hold in memory.
- Documenting Architecture DecisionsNygard's decision-record format preserves context and consequences while the reasons for a choice are still available.
- DORA metricsA software-delivery example of deciding with measured signals rather than team confidence.
I notice, rereading the list, that none of these are about technology. That tracks. The technical decisions change with every project; these are the ones that follow me from project to project, which is how I know they're mine.