A Good Question Includes Your Best Guess

·https://jvns.ca/blog/good-questions/
articlecommunicationlearningdebuggingengineering-culturethinking

maps directly to how agents should formulate stuck-points in the reviewer/judge loop steps — a hypothesis is better than a blank help request

Julia Evans has a gift for taking things engineers think they already know and making the actual shape of the thing visible. Her post on asking good questions does exactly that — it’s not about politeness or social dynamics, it’s about the structure of a question that actually gets answered.

The core move: include your best guess. Not “how does X work?” but “I think X works by doing Y because of Z — is that right?” That one shift changes the entire interaction. It gives the person answering something to confirm, correct, or extend. It shows you’ve thought. And counterintuitively, being wrong in a specific way is more useful than being vague in a neutral way. A wrong hypothesis is a starting point. A blank question is just a request to think for you.

The other piece that sticks is the discipline of stating what you already know and what you’ve already tried. This is about not making the other person waste effort explaining things you’ve already ruled out. It’s compression — you’re handing them a diff instead of the whole source tree. That’s a form of respect for their attention.

This connects to how I think about agent loops and prompt design. When a dagWorker stage gets stuck, the quality of what it surfaces back is exactly this problem — a vague “I can’t do this” is worthless, but “I tried X, my best guess is that the issue is Y, here’s what I’d check next” is something the orchestrator can actually act on. Good questions are a protocol, not just a social skill.

Key Ideas

  • Include your best guess — even a wrong hypothesis is more useful than an open-ended question because it gives the responder something concrete to correct
  • State what you already know — compress the shared context so the other person doesn’t re-explain what you’ve already ruled out
  • Be specific about what you’ve tried — shows effort and narrows the solution space immediately
  • Wrong + specific beats vague + neutral — precision in being wrong is epistemically more productive than perfectly calibrated uncertainty
  • Julia Evans writes zines that apply this same “make the structure visible” approach to networking, git, SQL, and systems topics
  • The pattern maps to rubber duck debugging — articulating the question fully often surfaces the answer before anyone responds
  • Connects to how agent stages should report blockers — a stuck agent with a hypothesis is recoverable; a stuck agent with silence is a dead end

Links

← All discoveries