A developer posts: "My Postgres connection pool keeps exhausting under load, what am I missing?"

You know six things that could be wrong. Pool size. Idle timeout. Long-running queries. Connection leaks in the ORM. PgBouncer mode. The fact that they're probably running on a tiny instance.

You write all six up. Bullet points. Sub-bullets. A footnote about pg_stat_activity. You hit submit feeling helpful.

It gets two upvotes and a reply that says "thanks ChatGPT."

What's actually happening

A long, comprehensive reply does three things to the reader at once: it asks them to evaluate six possibilities, it implies you didn't read their post carefully enough to pick the right one, and it pattern-matches to the kind of brain-dump LLMs produce by default. None of those build trust.

A short, specific reply does the opposite. It says: I read your post, I have a hypothesis, here's how to confirm it, here's the fix.

That second shape is what humans who actually debugged the problem in the wild tend to write. They have a candidate cause in mind, not a checklist.

The selection step matters more than the writing

The skill isn't writing concisely — it's picking the one fix to lead with. A few heuristics that work:

Most likely given the symptoms. Pool exhaustion under load with no other detail? Lead with idle connections held open by long-running transactions. That's the modal cause.
Easiest to verify. If two causes are equally likely, lead with the one they can check in 30 seconds, not the one that requires changing config and redeploying.
The cause they probably haven't considered. If they've already mentioned trying the obvious thing, your edge is naming the non-obvious one.

The other five fixes don't disappear — they go in a follow-up paragraph that starts "if that's not it, the next places I'd look are…". The structure puts the bet first and the alternatives second.

Before and after

Before (comprehensive, gets ignored):

A few things to check:

Pool size — try increasing max_connections

Idle timeout — set idle_timeout to 30s

Connection leaks — make sure your ORM closes connections

PgBouncer mode — try transaction pooling

Instance size — your server might be undersized

Long-running queries — check pg_stat_activity

After (focused, lands):

Sounds like idle connections held by long transactions. Run SELECT pid, state, query_start, query FROM pg_stat_activity WHERE state = 'idle in transaction' — if you see anything sitting there for more than a few seconds, that's it. Usual culprit is an ORM transaction not being closed in an error path. If that's clean, next thing I'd look at is idle_in_transaction_session_timeout.

Same information density, but the second one reads like a person who's debugged this before.

When multi-fix replies actually work

Long, structured replies have their place — they just don't belong as a first response to a question. They work when:

The OP has narrowed it down and is asking for a checklist explicitly ("what should I check?")
You're writing a top-level post or a wiki entry, not a thread reply
The audience is intermediate-plus and skimming for breadth

The signal is the OP's framing. If they describe a specific symptom, give them a specific guess. If they ask for a list, give them a list.

A self-check before you hit submit

Read your draft and ask: would a stranger believe a human wrote this in three minutes after recognizing the symptom? If the answer is "no, this looks like someone enumerated possibilities," cut to the one that matters most. Move the rest to a one-line addendum.

The shape of your reply tells the reader more about you than the content does.