About

How I build, how I think, and what this site deliberately leaves out.

How I Build
Each line here is a decision made before the first ticket is written.
Interview first.
Never take a request at face value, dig to real intent before building. The right spec answers the right question.
Write specs engineers build from.
Config-vs-code decided up front. Every item resolves to a fixture, a signature, or a runbook, never prose that leaves room to guess.
Map edge cases before the build.
The edge case that slips into production is the one nobody asked about in the spec.
QA with evidence.
A repeatable test method and client-facing UAT packs that carry regression coverage forward every release.
Prioritise by demand.
P0 through P3 by who is actually asking. Effort tells me the cost, never the priority.
Migrate with discipline.
Schema analysis, field mapping, validation, staged execution with review gates. No surprises in production.
Own security.
ISO 27001 gap analysis, Statement of Applicability approver, quarterly compliance reviews. Security is product work, owned from the start, not a checklist handed to a different team.
How I Think
Placed after the work section on purpose: the shipped scale earns the right to talk about thinking.
  • I start from first principles. If the reasoning does not hold from the ground up, the conclusion does not hold.
  • I change my mind when the evidence does, on the pattern rather than every signal.
  • I look for what the data is missing. The absence of evidence is where I start reading.
  • I watch for coordination failures, situations where everyone does the individually rational thing and the group outcome is bad. Most product problems I have debugged turned out to be that.
  • The most important data point is the one that never arrived.
What Would Change My Mind
A list I keep and act on: when one of these fires, the method changes.
  1. If a feature I prioritised P0 ships and nobody who asked for it uses it, the demand-driven framework was reading the wrong signal, and the framework is what I fix.
  2. If a coordination failure I diagnosed turns out to be a plain execution gap once I look closer, I revise the diagnosis, not the story.
  3. If the pattern across three release cycles contradicts the pattern I called after one, the one call was noise.
  4. If an edge case mapped before a build still slips into production, the mapping process has a hole, not the engineer who missed it.
What's Not Here

The ring stays empty on purpose.

  • Employer and client names. I reference them by scale and sector instead.
  • Numbers I can't back up. Everything quoted here can be checked.
  • The next chapter. The route ends at now.
Same argument as The Mark below, told twice: once as a diagram, once as a plain list. If a bomber makes it home with holes in the wings, the wings were never the problem.

The mark is a return flight.

In 1943, the US military mapped the bullet holes on bombers returning from Europe, wanting to armour the places hit most. The statistician Abraham Wald turned that inside out: the planes that came back survived those hits, that's why they were visible. Armour instead went where there were no holes, because planes hit there never made it home.

The mark draws that inversion directly: a top-view plane, seven amber hits on the wings and tail, and a dashed ring at the nose, drawn around nothing. The data in front of you is the data that survived: the empty ring is the whole argument.

Wald's actual method, and why the famous bullet-hole diagram is a reconstruction rather than his data, is shelved in the Reading Room.

Shelf

every book I own, with a line on each, is in the library →