Query, Refine, Yield

The QRY methodology isn't revolutionary. It's just systematic. When you encounter problems repeatedly, you can either keep complaining or start documenting patterns and building better solutions.

This is what I've learned works for turning institutional dysfunction into useful tools.

Query: Document what's actually broken

Before building anything, figure out what the real problem is. Not the symptom everyone complains about, but the underlying dysfunction that keeps causing the same issues.

  • Document patterns: When does this problem happen? What triggers it?
  • Identify root causes: Why do current solutions fail? What assumptions are wrong?
  • Map the dysfunction: How does the broken system actually work? Who gets hurt?
Example: "Good work stays invisible" → systematic documentation reveals that velocity metrics punish thoroughness while depending on quality outcomes.

Refine: Build focused solutions, test with real problems

Build the minimum viable tool that solves the documented problem. Test it with actual dysfunction, not idealized scenarios. Iterate based on what breaks.

  • Start small: Solve one specific aspect of the problem completely
  • Test with chaos: Use it in real situations with real constraints and interruptions
  • Document failures: What breaks? What assumptions were wrong? What works unexpectedly well?
Example: uroboro captures development context → tested during actual deadline pressure → refined to handle interruptions and context switching.

Yield: Share what works so others can adapt it

Document the solution completely. Not just the code, but the problem it solves, why other approaches failed, and how others can adapt it to their situations.

  • Share the methodology: How did you approach the problem? What can be transferred?
  • Document limitations: What doesn't this solve? What are the sharp edges?
  • Enable adaptation: How can others modify this for their specific dysfunction?
Example: QRY methodology itself → documented completely → others can adapt systematic problem-solving to their domains.

Why this works

Most problem-solving approaches either jump straight to solutions (missing the real problem) or get stuck in analysis paralysis (never building anything). QRY forces you through all three phases systematically.

The documentation component is crucial. If you can't explain the problem clearly, you probably don't understand it. If you can't document the solution, others can't benefit from your work.

"I learn to spite those who punish it. If I can suffer and learn and build systems that prevent others from experiencing that dysfunction, then the suffering becomes valuable."

Current applications

The QRY methodology is being applied across several domains:

  • Developer tools: Local-first solutions to surveillance-heavy productivity software
  • Educational games: Making complex concepts accessible without oversimplification
  • AI collaboration: Transparent integration that builds capability rather than dependency
  • Institutional dysfunction:Converting toxic experiences into systematic knowledge

Try it yourself

Pick a problem you encounter repeatedly. Document what's actually broken. Build the smallest thing that might help. Share what you learn.

github.com/QRY91 →Read the story →