Why 'Can You Check This?' Is an Expensive Message
Four words cost you nothing to type and thirty minutes of someone else's context to answer. The shorter message is often the more expensive one.
Someone on your team sends four words: "Can you check this?" No link that resolves to anything specific, no file name, no line, just the question. It takes them eight seconds to write. It takes you twenty minutes to figure out what "this" is, what "check" means, and whether you're supposed to fix it, approve it, or just glance at it and say fine.
That trade is not a bargain. It looks efficient because the sender's cost is visible and yours isn't. The message shows up in your inbox as four words. The actual cost shows up an hour later as you scroll back through three threads trying to guess what they meant, and it doesn't show up anywhere they can see it.
The message is short. The task it creates is not.
A vague request doesn't skip the work of specifying the task. It just moves that work onto the person who has to answer it, and it does the move badly, because they don't have the context the sender had when they typed it. The sender knew which file. The sender knew what "check" meant in their head — probably "tell me if this logic handles the refund case," not "read the whole thing." None of that made it into the message.
So the recipient has to reconstruct intent before they can do the actual work. Reconstructing intent is a different skill than reviewing code or approving copy, and it's the part that eats the time. You can review a diff in three minutes once you know what you're looking for. You can burn twenty minutes just finding the diff and guessing what you're looking for.
Three versions of the same ask
Take a real one: a developer wants a teammate to look at a pull request before it merges. Here's the message that costs the least to send and the most to receive:
“Can you check this? https://github.com/example/pr/482”
The recipient now has to open the link, figure out which files changed, guess whether "check" means "read for bugs," "approve the whole thing," or "tell me if the tests look right," and decide whether this is due now or whenever they get to it. If they guess wrong, the developer replies later with the actual concern, and now it's a second round trip instead of one.
A slightly better version names the object:
“Can you review the PR for the refund flow? Link above. Let me know if the edge case where a user cancels twice looks right to you.”
Better. Now the reviewer knows where to look. But they still don't know if this is urgent, and they don't know what "looks right" would even mean — is there a spec, a ticket, a Slack thread from three weeks ago where someone described the intended behavior?
The version that actually saves time carries four things: the object, the expected outcome, the evidence, and the urgency.
“PR #482 changes the refund flow. Can you confirm the double-cancel edge case is handled — specifically that a second cancel request doesn't trigger a second refund? Test case and expected output are in the PR description. Needs to merge before end of day, since it's blocking the release.”
That message takes maybe forty extra seconds to write. It saves the reviewer the twenty minutes of guessing, and it saves the sender the second message they'd otherwise have to send once the first guess came back wrong.
Why the short version feels reasonable to send
Nobody writes "can you check this" out of laziness exactly. They write it because the full context is sitting in their head, so vividly present that they forget it isn't in the recipient's head too. This is the same failure that makes people say "you know what I mean" — they do know what they mean, and they've mistaken that clarity for something they've already communicated.
There's also a social cost to writing the long version that the short version avoids. A long, specific message can feel like it's assuming the recipient is dumb, or like it's padding a simple ask with unnecessary detail. But specificity isn't padding. "Confirm the double-cancel edge case is handled" is not more words for the sake of politeness — it's the actual content of the request. Without it, there is no request, just a question mark pointed at a link.
The four things a request needs to not be expensive
- Object — the specific thing, not the general area. "The refund flow in PR #482," not "this."
- Expected outcome — what a correct answer looks like. "Confirm X doesn't happen," not "let me know what you think."
- Evidence — where the recipient can verify without asking a follow-up question. A test case, a screenshot, a line number.
- Urgency — whether this is now, today, or whenever. Silence on urgency gets read as "now" by anxious people and "whenever" by everyone else, which means you get the wrong one about half the time.
Miss any one of these and the recipient has to ask a clarifying question, which is its own tax: another context switch, another wait, another place for the thread to die on a Friday afternoon.
Where this shows up worse: async and cross-timezone teams
In an office, "can you check this?" gets clarified in the next ten seconds because you're both standing there. Async, the gap between the vague message and the clarifying question can be a full working day. Someone in Lisbon sends "can you check this" at 5pm their time. Someone in Austin sees it at 9am their time, doesn't know what it means, asks a clarifying question, and now the answer waits another eight hours for Lisbon to wake up. A request that could have been resolved in one exchange takes two full days because the first message left out three of the four things it needed.
This is also where the distinction between a task and an ask matters. A vague "check this" is neither — it's not owned work with a clear deliverable, and it's not phrased as a specific ask someone can act on without a follow-up question. Writing it as a proper request, with the object and outcome named, does most of the work of making it resolvable in one round trip regardless of which system it lands in.
The discipline is writing the message as if you won't be there to explain it
A useful test before sending: if you disappeared for six hours right after sending this, could the other person still act on it correctly? "Can you check this?" fails that test completely — it depends on you being reachable for the inevitable "check what, exactly?" The four-part version passes it. The recipient can act on it at 2am your time, in a different city, having never talked to you about this before, because the message did the work of being a message instead of a placeholder for a conversation.
