Developer community outreach & authentic replies

A dev posts "my Postgres connection pool keeps exhausting under load, what am I missing?" You know six things it could be — pool size, idle timeout, long-running queries, ORM connection leaks, PgBouncer mode, an undersized instance — so you write all six up with bullets and a footnote about pg_stat_activity. Two upvotes and a "thanks ChatGPT."

A long, comprehensive reply does three unhelpful things at once: it asks the reader to evaluate six possibilities, it implies you didn't read carefully enough to pick the right one, and it pattern-matches to the brain-dump LLMs produce by default. 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's what someone who actually debugged the problem tends to write; they lead with a candidate cause, not a checklist.

The real skill is compression, and compression is diagnosis, not brevity. Run your long answer through three passes: (1) name the single most likely cause given the specific symptoms — for pool exhaustion under load, that's idle-in-transaction connections, not "there are many reasons pools exhaust"; (2) give the one verification step, concrete and doable in 30 seconds — SELECT pid, state, query_start FROM pg_stat_activity WHERE state = 'idle in transaction'; (3) name the one most likely next branch if that's clean (idle_in_transaction_session_timeout). Stop at two. That's three sentences carrying ~80% of the value at ~30% of the cognitive load. The other five fixes don't vanish — they live in a follow-up that starts "if that's not it, next I'd look at…". Compression only stays wrong when the OP explicitly asks for a checklist, when you're writing docs, or when three causes are genuinely equally likely — then ask one diagnostic question instead.

The disorienting part: a technically perfect reply with shape-tells draws more suspicion, not less. The reader can't audit your reasoning, so they audit your style — "too clean, too complete, too polished, looks like a model produced it." Given how much AI text floods these channels now, that's a reasonable prior, not an unfair one.

The tells are knowable. Ranked roughly by how loud each is:

1. Canned openers — "Great question!", "This is a common issue", "Thank you for reaching out", "I understand how frustrating this must be." The single loudest tell. No human types these in chat unless trained to.
2. A five-to-seven-item list where you wanted three. LLMs default to enumerative completeness; humans pick the two that matter and skip the rest.
3. Section headings (###) on a comment-length reply.
4. Soft transitions — "Additionally," "Furthermore," "It's worth noting that," "You can also consider…"
5. Generic principles where specifics belong — "follow security best practices" instead of "don't put your OPENAI_API_KEY in the repo, use .env plus dotenv." Specifics earn trust; generics burn it.
6. A summary paragraph — "In summary, by addressing X, Y, and Z…"
7. Suspiciously perfect grammar across long, comma-spliced sentences. Real chat has fragments, lowercase, and comma splices.

Three of these gets you sniffed out; five gets you dismissed. The fix is a 90-second second pass over any draft: cut the opener and start with the answer; trim a five-item list to two; replace one generic sentence with a specific one that could only apply to this person's problem; add one sentence that proves you read their post (quote a phrase, name their stack, disagree with a small assumption); drop a heading; and leave one slightly imperfect sentence, because chat actually contains those. The goal isn't to fake humanity — it's to stop writing in the register AI uses by default, which most humans don't naturally use either.

A polished reply on Reddit reads like a press release, and "polished" isn't a compliment in places where the audience has been burned by both AI slop and marketing agencies. This isn't an argument for sloppy writing — it's an argument for calibrated writing. The medium has its own register, and overshooting it costs you trust faster than undershooting it.

What a reader's pattern matcher flags as too clean, when all of it stacks up in one short comment: every sentence grammatically perfect and fully punctuated; no casual contractions (all "I am" / "you are," never "I'm" / "you're"); no filler like "tbh," "fwiw," "yeah," "so"; clean transitions ("Furthermore," "Additionally"); the editor's em-dash every other paragraph; a thesis as the first sentence and a conclusion as the last; bulleted lists with parallel grammar. Each one alone is fine. All together, they sound like an article, and articles don't belong in comment threads.

What reads as "a real person typed this": a sentence fragment in the middle, for emphasis; a lowercase start after a dash; a parenthetical aside that runs longer than the main clause; one over-long comma-spliced sentence because that's how the writer was actually thinking; a typo left because the meaning was clear; calibration words like "honestly" and "to be fair"; and specifics only someone who'd done the thing would know. Naming yourself as previously wrong ("used to think X, turned out it was Y") is especially credible.

The practical routine is two passes: first, write like a person who debugged this last week — type fast, don't backspace, leave fragments. Second, fix factual mistakes and ambiguity but don't smooth the texture; keep the contraction, keep the sentence that starts with "so." Polish earns its place in long-form — a blog post, a Show HN, docs — because the form telegraphs effort. The mismatch only hurts when polish-level outruns the medium: a polished one-paragraph reply on r/selfhosted is uncanny. Removing the artificial polish isn't faking authenticity; it's declining to over-edit what a real reply naturally sounds like.

Every reply has an implicit structure budget — headings, bullets, bold, code blocks, tables. Spending it signals "I'm presenting organized information," which is right for docs, blog posts, and answers that took an hour to research. It's the wrong signal for a first reply in a chat thread, because heavy structure implies prepared output, and prepared output implies someone (or something) sat down to assemble it. That tells the reader you're writing at them, not with them.

Compare. The over-structured first reply to "why is my connection pool exhausting?" has an H2, three subheadings ("Common causes," "How to investigate," "Recommended fixes"), and two bulleted lists. It's accurate and it reads like a Confluence page someone scraped. The right-sized version spends almost none of the budget: "Probably idle connections held by transactions that aren't getting closed. Run SELECT pid, state, query_start FROM pg_stat_activity WHERE state = 'idle in transaction' — anything older than a few seconds is it, usually an ORM error path that doesn't release. If that's clean, next I'd check idle_in_transaction_session_timeout and your PgBouncer mode." Zero headings, one inline snippet, same information density — it reads like a Slack DM from someone who saw this last week.

To convert a structured draft into a conversational first reply: (1) drop the headings — almost always unnecessary in a comment; (2) collapse the top-level bullets into one paragraph, using "so," "the usual culprit," "if that's clean, then" as connectors; (3) keep at most one structured element if it earns its place — a snippet they should literally run, or a two-line list at the very end. You'll feel like you removed information; you only removed visual hierarchy. Spend the budget on top-level posts, genuinely multi-step procedures, replies explicitly asked for as a list, and later turns after the conversation has narrowed. The one exception: inline and fenced code always earn their place — code makes content unambiguous and doesn't trip the template alarm.

That's exactly the problem: you changed nothing, and sameness itself is the tell. The thing that gives you away isn't the words — it's the rhythm. Every reader runs a fast, mostly-unconscious model of "how a real comment sounds": sentence lengths vary, openers aren't always the same shape, some replies have no conclusion. When you author the same kind of reply thirty times — even with the actual sentences swapped out — your macro structure is the constant, and that macro shape becomes the signal. People don't consciously detect it, but their bot-detector fires anyway. It's why a song with the same beat under different melodies still sounds like one band.

Four rhythm dimensions leak templates. Opener shape — if they're all questions, or all "This sounds like…", or all "Have you tried…", pick three and rotate. Sentence-length distribution — templates trend toward medium sentences; real replies have one-word sentences, long comma-spliced ones, fragments. Paragraph count — three short paragraphs every single time is a template smell; sometimes one paragraph is right, sometimes seven. Signoff — "Hope that helps!" at the bottom of every reply is a tell so loud you might as well sign "Sent from my Marketing Department."

Audit yourself: open your last 20 outreach replies in one document and scroll through without reading the words — just look at the shape, paragraph count, length. If they look identical when blurred, you have a template problem no matter what the sentences say. Second pass: read only the first sentence of each, in order, as a list; if it sounds like a poem with a meter, that's bad, if it sounds like 20 different humans, that's good. Vary all four dimensions and you can repeat the same content angle without anyone noticing. The strategic version is bigger: stop treating outreach as a campaign with a template and start treating each reply as one specific person answering one specific question.

Communities aren't anti-marketing — they're anti-link-drop, and the difference is everything. The immune response fires on obvious cues: a week-old account, post history only in threads where the tool is on-topic, every reply ending in a link, none of them actually helping. The reflex is anti-extractive: the community correctly senses you're harvesting their attention to grow yours without giving back. The fix isn't being sneakier about the link — it's giving back first.

Value-first means solving the person's problem completely without mentioning your tool. Worked example — someone asks "cleanest way to run Claude Code, Codex, and Gemini CLI in parallel without four terminal windows?" The spam-reflex reply is "I built [Tool] for exactly this — [link]." The value-first reply gives the actual tmux answer (tmux new -s ai \; split-window -h \; split-window -v), names the real pain points (visual context switching, keeping sessions alive across reboots, pulling output between panes), says tmux + tmuxp fixes the first two, and then discloses: "(Disclosure: I work on a tool that wraps this into a desktop workspace, so I'm biased — but tmux is the right starting point.)" It's twice as long and it's the one that builds trust.

The disclosure pattern does three things at once — transparent about your interest, honest about your bias, and volunteering that the tool isn't always the right answer ("would be overkill until you outgrow it"). That moves you from "shill" to "person who happens to have built something adjacent." Two guardrails make it sustainable: the 80/20 rule — make 80% of your replies in threads where your tool isn't relevant, so the 20% where it is read as informed contributions, not pitches; and drop a link only after you've helped a few times, phrased as an offer, not a push ("if you want to skip the tmux setup, [tool] does the same thing — no pressure, your setup will work fine"). What kills it: templated replies across threads (readers pattern-match you to a bot), a profile bio that's only your tool, and following up every reply with "did you try [Tool]?" Help, then move on. The slow path feels inefficient and compounds into a real audience; the shortcut feels efficient and produces nothing.

The format isn't wrong — the medium is. Discord and Slack are conversational; runbooks are documentation. The four-field shape (error, cause, fix, verify) needs to compress and warm up to land in a chat thread, or users perceive it as scripted and engagement drops.

The compressed shape fits in about 100–200 characters: "Sounds like [cause]. Try [fix] — should resolve in [time]. Confirm by [watching for X]." Three sentences max. Take a runbook entry like "ERROR: nginx 502 upstream prematurely closed / CAUSE: PHP-FPM killed under load at memory_limit / FIX: raise memory_limit to 512M, restart fpm / VERIFY: tail nginx error log, no 502s under load." The support-channel variant: "Sounds like PHP-FPM hit its memory limit under load and got killed — common with image uploads. Try bumping memory_limit to 512M in php.ini and restarting FPM. Should fix immediately; watch your nginx error log to confirm no more 502s." Same diagnostic, same fix, same verification — different register.

Three things get adapted: the opener softens ("ERROR" → "Sounds like," framed as a hypothesis the user can disagree with); the why folds into the fix ("X happened because Y, fix is Z" as one thought instead of split CAUSE/FIX fields); and verify becomes "watch for" — not "run this command and check output" (reads as homework) but "should resolve immediately, tell me if it doesn't," which puts the burden on you. Keep it to connected prose: no bullet points (they signal template) and no headings (they signal documentation).

Templates cost you a little detectability — a repeat customer will eventually notice the pattern — but they buy consistency, completeness (the verify step doesn't get dropped under pressure), and trainability for new support staff. Reduce the detectability by rotating the opener ("Sounds like" / "Bet it's" / "Probably" / "Looks like"). Skip the template when the user is upset (lead with acknowledgment), when the diagnosis is genuinely uncertain (ask one question instead), or past turn 3 (by then you should have specifics no template anticipates). Build the library by writing the compressed card during the fix, not later — 60 seconds after each resolution, and in a few months you can answer 80% of new questions by adapting an existing one.