DEV Community: Karan Thakkar

Art of a Good Message

Karan Thakkar — Sat, 31 Jan 2026 23:19:46 +0000

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.

Art of a Good Question

Karan Thakkar — Mon, 22 Dec 2025 19:56:47 +0000

"There are no bad questions."

It's a popular saying in tech. The intent is good: we want to create psychological safety and lower the barrier for juniors asking for help. But while there may be no bad intentions behind a question, there are certainly poorly framed ones. These aren't bad because the problem is simple; they are bad because the thinking behind them is incomplete.

I was reminded of this recently in a DevOps community chat. Someone asked for help with a query they were stuck on. No context. No constraints. No indication of the end goal. People asked for clarification, but the follow-ups added little. Eventually, the thread just died.

What actually broke down in that thread wasn't knowledge—it was the distribution of thinking.

Transferring the Load

We tend to view questions as simple requests for information. But really, they are transfers of cognitive load.

When you ask a vague question, you aren't just asking for an answer. You are asking the listener to reconstruct your mental model, guess at your missing constraints, and explore the solution space from scratch. You are asking them to do the work you haven't done yet.

A well-formed question carries the weight of that work already. A poorly formed one offloads it entirely onto the listener. This is why vague questions feel "low effort."

The Difference in Practice

You see this friction most clearly when troubleshooting.

The High-Load Question:

"My deployment isn't working. It works on my machine but fails in prod. Any idea what's wrong?"

There is no meaningful way to answer this. The responder is forced to play a guessing game. What is being deployed? Where? What does "not working" actually mean?

The Low-Load Question:

"I'm deploying a containerized service to Kubernetes. The pod starts but crashes after ~30 seconds. Logs show a database connection timeout. The database is reachable from other pods in the same namespace. What else should I be checking?"

This question respects the responder's time. It contains observed behavior, constraints, and eliminated possibilities. Even if the responder doesn't know the answer, they know where to look next.

The XY Trap

Formulating a good question is hard because it forces you to confront the shape of the problem before you understand it. It forces you to avoid the "XY Problem"—asking how to fix your attempted solution (Y) instead of the actual root problem (X).

For example: You ask how to increase a connection timeout (Y), when the real issue is that your service depends on a database that isn't ready yet (X).

To ask a good question, you have to back up and define the reality of (X):

What exactly is failing?
What outcome am I actually trying to achieve?
What assumptions am I making?

Answering these forces you to think. And this is where something interesting happens: The act of preparing the question often dissolves the problem.

Engineers experience this constantly. You start writing a bug report and realize it's a race condition. You draft a message to a staff engineer and solve it halfway through. The answer didn't come from outside; it emerged because you were forced to structure your confusion.

The AI Parallel

This rigorous definition of the problem is exactly what modern tools demand of us.

The rise of LLMs has taught us this lesson by force. They call it "Prompt Engineering," but it's really just rigorous questioning. If you give ChatGPT a vague prompt, you get a hallucination. If you give a senior engineer a vague question, you get a decline to the meeting invite with a '?'.

In an era of instant AI and abundance of answers, the quality of your question matters even more. Clarity produces insight; confusion just produces noise.

The Pre-Send Test

Before you ask a technical question—to a colleague, a forum, or an AI—run it through this filter. If you can't answer these, the question isn't ready.

Context: Where is this running, and what is different from where it works?
Goal: What outcome do I actually want (not just the method I'm currently trying)?
Failure: What observable behavior proves it is broken?
Attempts: What explanations have I already eliminated?

Instead of treating questions as something you ask before thinking, treat them as the final artifact of thinking.

When you can articulate the gap between what you know and what you need, you are usually already halfway to the answer. Good questions aren't requests for answers. They are evidence of work already done.