This week I wrote about two things that have nothing to do with each other.
On Saturday it was a debugging story: a service was losing 30% of its UDP packets, I spent the better part of a day convinced a switch was dying, and the network turned out to be completely innocent — my own host was accepting the datagrams and then dropping them because a socket buffer kept filling during bursts. One kernel counter (netstat -su, "receive buffer errors") would have told me that in about ten seconds.
Earlier in the week it was product stuff: why teams keep losing their best work, why a freelancer's Friday disappears into "what was I even doing on Tuesday," why a marketing team rewrites the same prompt every quarter.
It wasn't until I sat down to write this recap that I noticed they're the same lesson.
The shared mistake
In the packet story, the expensive move was theorizing about why before establishing where. "The network is dropping packets" is a theory about cause. It sent me to the wrong team, the wrong dashboards, the wrong week. The cheap move — the one I skipped — was localizing first: are the packets dying on the wire, or after they reach my box? Two completely different buildings, identical symptom.
Product decisions have the exact same failure mode. "Users churn because we're missing feature X" is a theory about why. It's also, usually, the most expensive possible thing to act on first, because building X takes a quarter and the theory might be wrong. The cheap move is to localize: where in the week, the workflow, or the funnel does the value actually leak out?
When you force yourself to find where first, the answer is often boring and small — and boring and small is good news, because boring and small is cheap to fix.
Why I keep coming back to this
Both of the things I work on are, underneath the marketing, just instruments for making "where" visible.
FillTheTimesheet exists because "I undercharged this month" is a why-theory; the useful version is where the billable hours actually went, captured while they happened instead of reconstructed on Friday.
PromptShip is the same shape pointed at a different problem: "our team is bad at AI" is a why-theory; "the prompt that worked is sitting in one person's chat history and nobody else can find it" is a where. One is an identity crisis, the other is a Tuesday-afternoon fix.
Neither is glamorous. Both are counters you check before you theorize.
The Sunday takeaway
Find where before you theorize why. It works on packets, it works on churn, and it works on most arguments that have gone in circles for more than ten minutes. Locate the problem in space before you start explaining it — the explanation is usually cheaper, and more often correct, once you know where you're standing.
The full UDP debugging story, counters and buffer math included, is on Medium if that's your kind of weekend reading: I Lost 30% of My UDP Packets — The Debugging Story.
What's the last thing you assumed the cause of — before you actually measured where it was happening?
Top comments (0)