field notes

Writing

Short notes from real engineering work: one decision, one incident, one reversal at a time. Each one names the shape of the problem, the tension that made it hard, the decision, and what it cost. The internals stay out — the codename is the hint.

If you have five minutes rather than an afternoon: the three case studies condense this material to one problem, one decision and what the decision cost. The notes below are the record those studies cite — and the projects the codenames belong to are on the front page.

source notes/ · 252 notes · 10 codenames · newest first · atom feed

All field notes

filter by theme · 244 total

the history is also reviewable

Code review looks at what changed. A second kind of review looks at how it changed, across a stretch of the mainline, and asks whether the record can be read by somebody who was not there. That review found four classes of drift and no…

read

consent a customer can actually read

The registration form is where a platform's promises become a customer's problem, so it is the wrong place for a single combined checkbox. The change that landed separated the agreements from the marketing permission, linked each required…

read

one answer instead of a wall of denials

A staff dashboard has to know what the person in front of it may see before it renders anything. The direct way is to ask about each protected area and see which answers come back. Every one of those questions is legitimate, and the browser…

read

the flake was in the isolation, not the code

Two failures in the same period, and neither was a defect in the product. A totals assertion failed once in a run and passed on the retry. A later step in an unrelated scenario answered not-found for a row the test had just created. Both…

read

the exposed default, made impossible

A development database was published on every network interface rather than the loopback one. It was found by a scanner, brute-forced, and left carrying a back door. Nobody had decided to expose it. The default mapping did that, and every…

read

events that cannot precede their commit

A live board for staff is a latency problem that is really a truth problem. The obvious implementation is an in-process broadcast: when state changes, publish. It is fast, it is simple, and it makes it possible for a board to display a…

read

verify the artifact, not the source

Verification kept producing a specific kind of wrong answer. The tree was correct, the local build was correct, the browser checks were green, and the thing users were actually loading was older than all of it. Two mechanisms were…

read

the numbers the product will not invent

Sample content has a way of surviving into production. A review section carried a demonstration fallback: a few plausible reviews and an average just under five stars, rendered when the real fetch failed. It existed to make review builds…

read

registration is not deployment

Bringing a new business onto the platform looks like one operation and is really two. There is the record of the business: its identity, its routing key, its configuration, and a starter menu attributed to it. And there is the deployment of…

read

method

What a field note is

Not a changelog entry and not a repository summary. One decision, one incident, one reversal, or one hard-won invariant — the thing an engineer would tell you at a whiteboard.

shape
What made the problem genuinely hard, before any solution appeared.
tension
The two things that could not both be true — stated precisely, because that is the part that transfers.
decision
What was chosen, and what it cost. Cost is the credibility; a decision with no cost attached has not been described.
ceiling
A codename, a theme, and a class of problem — never a hostname, a parameter, a version or a vendor. Under the disclosure rules the hint is the category, not the instance.

Prefer records with dates and root causes? Those are on incidents. Live numbers are on stats.