In a previous post, I argued that a good question is the artifact of thinking, not the starting point. This post picks up where that one left off: once you've done the thinking, how do you transmit it without losing signal?
Can you grab me a coffee?
You text your friend: "Can you grab me a coffee?"
They come back with a medium black coffee. You wanted a large oat milk latte with an extra shot.
Now flip it. You text: "Hey! So I've been really tired lately because I stayed up watching that new series—you know, the one with the detective? Anyway, I didn't sleep well and I have this big meeting at 3 PM, and you know how I get when I'm tired, I just can't focus, and I remember last time I had a coffee it really helped, but not too much caffeine because then I get jittery, and I think it was a Tuesday when—"
Your friend stops reading halfway through and guesses: medium black coffee.
Both failures land in the same place. Too little context forces guessing. Too much context causes people to tune out and guess anyway.
The sweet spot looks like this: "Large oat milk latte, extra shot, please."
We get this instinctively offline. We don't give the mechanic our autobiography. We don't warm up a doctor with a ten-minute preamble. Somewhere between silence and a monologue, there's a narrow band where communication actually works.
That instinct vanishes the moment we open Slack.
Please Help!!!
I've received bug reports that said only: "It's broken."
I've also received reports with a week of terminal history, full laptop specs, screenshots of unrelated errors, and a detour about why microservices were a mistake.
Neither helped.
Engineers obsess over efficiency in systems. We trim Docker images by megabytes. We debate API payload sizes. We care deeply about latency. Then we fire off a one-line drive-by or dump our entire mental state into a chat window and expect someone else to parse it.
Lessons from Logging
I once had to overhaul a legacy logging system—the kind that had grown untouched for years across multiple teams. A single authentication attempt scattered logs across four files. Debugging meant reconstructing events from fragments that were never meant to fit together.
The fix wasn't "log more." It was the opposite.
We moved to structured logging. One event, one entry. Fields chosen deliberately. The hard part wasn't picking the format—it was deciding what not to include.
{
"timestamp": "2026-02-01T14:30:00Z",
"level": "error",
"event": "payment.declined",
"transaction_id": "txn_8842abcd",
"amount": 4900,
"currency": "USD",
"gateway": "stripe",
"reason": "insufficient_funds",
"latency_ms": 142
}
We could log everything: user agent, device type, geo data, referrer, browser version. Most of it was useless most of the time; noise dressed up as thoroughness.
The question that guided every decision: If I'm triaging this at 2 AM, what do I actually need to understand what happened?
That question applies just as cleanly to how we talk to each other.
Context is Serialization
When you ask for help, you're serializing your understanding of a problem so someone else can reconstruct it.
That payload usually needs a few things:
- What you're trying to do
- What's happening instead
- Where it's happening
- What changed recently
- What you've already ruled out
Leave out too much and reconstruction fails. Include everything and the schema gets buried. The reader skims, latches onto something familiar, and starts guessing.
In production, we don't log the entire application state on every error. We log the fields that let us reason about it. Communication works the same way.
The Curse of Knowledge
Most bad context isn't laziness. It's assumption.
You know which environment you're in. You know which service you restarted. You know what "the API" refers to. The person reading your message doesn't.
So the conversation turns into context recovery:
"Which environment?"
"Did you restart it?"
"What error?"
"When did this start?"
Four round-trips before anyone's actually debugging.
A Simple Schema
Before you send a message asking for help, run it against a quick checklist:
- What's happening?
- What should be happening?
- Where is this occurring?
- What changed recently?
- What have you already tried?
Not every message needs all five. But if the answers live only in your head, the payload's incomplete.
The Payoff
The first post was about the protocol—how to ask well. This one's about the payload—what you actually send.
Clear context is operational empathy. The person on the other end has limited attention, their own priorities, and no access to the assumptions in your head. If you don't curate your context, they have to.
Optimize for humans the same way you'd optimize a system.
Send signal. Strip noise. And always include the environment.
Top comments (0)