Home
EngineeringPrinciples

How I work

Six things I actually believe about building software, each one attached to the system that taught it to me. No principles without receipts.

01

The model is the small part

The model call in the stroke-rehab backend I worked on is about thirty lines of Go. The rest is temp directories, frame-to-video conversion, upload retries, cleanup, and making sure a half-processed video never gets scored as a finished one. The model answers a question. Everything around it decides whether the question was asked correctly and whether the answer can be trusted to land.

02

When wrong is expensive, boring beats clever

On the UCSF Health and Stanford Medicine platform, a duplicate rep is not a minor bug, it is a corrupted patient record with a clinician looking at it. So that system runs on idempotent writes, explicit failure modes, and circuit breakers. It is deliberately unexciting, and that is the feature.

03

Derive identity from whatever makes an action distinct

Exactly-once delivery does not exist. What exists is at-least-once plus a storage layer that refuses to be fooled by duplicates. The change that mattered most in that codebase was widening a conflict key to the exercise, the patient, the rep, and the step together. Ten lines, and it is the difference between a retry and a corrupted record.

04

Validate what it did, not what it said

Prose can lie fluently. A program either compiles or it does not. The exercise generator emits Scenic programs that have to compile against a fixed library of allowed objects and actions, so a bad generation fails loudly instead of quietly producing something plausible.

05

Know which answer you can afford

The MILP I wrote at IMDEA is provably optimal and completely unusable past a hundred tasks. The greedy version is worse per task and finishes at a thousand. The result worth publishing was not either algorithm, it was the curve showing where to stop asking for optimal and start asking for done.

06

Catch bad data at the door

At Amazon, validating on ingest across 2M+ records removed about 70% of the manual toil on that path. Cleaning a bad record downstream costs roughly 10x more than refusing it at the boundary.

None of these are exotic ideas. They are the same lesson in different clothes: the impressive part of a system is rarely the part that decides whether it works.

— Amisha

Filed under: how I build