How to write X threads developers actually read (structure and examples)
By Naod Tadele · · 6 min read
A thread is a promise. The first post says "this is worth your next two minutes", and every post after it has to keep that promise. Most developer threads break it early: a vague opener, three posts of background, and the interesting part buried at the end where nobody reads it.
This guide covers when a thread is the right format, how to write the first post, a structure that works for technical topics, and what to cut.
When to write a thread (and when not to)
A thread is worth it when the idea has steps, a sequence or a story. A single post is better when the idea fits in one breath.
Good fits for a thread:
- A bug story. Symptom, wrong guesses, the real cause, the fix.
- A decision. What you chose, what you rejected, and why.
- A how-to. Steps someone can follow without leaving X.
- A launch or big release. Several features that each deserve a line.
- A lesson from a month of building. Three or four things you learned, with proof.
Bad fits: a small fix, a single number, a one-line opinion. Stretching those into a thread makes people feel tricked.
The first post does most of the work
On X, people decide from the first post whether to open the thread. It has to stand on its own and make the rest feel necessary.
What works:
- Lead with the result or the surprise. "Our alerts were wrong for two weeks and nobody noticed" beats "Some thoughts on alerting."
- Be specific. Name the tool, the bug, the number, the stack.
- Say what's coming. "Here's what caused it and how we found it" tells people why to keep reading.
- Skip the throat clearing. No "A thread on", no "Let me tell you a story." Start with the story.
Weak opener:
Some thoughts on how we handle incident grouping at Nightshift. A thread.
Stronger opener:
Nightshift grouped 40 alerts into one incident last night. Two weeks ago it would have grouped them into 9. Here's the one change that fixed it.
The second one has a before, an after and a reason to keep going.
A structure that works for technical threads
- Hook. The result or the surprise, in one or two lines.
- Context. One post. Who it affects and why it matters. Keep it short.
- The meat. Two to five posts, one idea each. This is the part people came for.
- The turn. What you'd do differently, the trade-off, or what surprised you.
- The close. A takeaway someone can use, then one link or one question.
Each post should make sense if someone sees it alone. People quote and share single posts from threads, so a post that only says "And then..." is wasted.
An example
Here is a short bug thread for a fictional on-call tool called Nightshift:
Nightshift grouped 40 alerts into one incident last night. Two weeks ago it would have grouped them into 9. Here's the one change that fixed it.
The problem: we grouped alerts by service name. But one bad deploy breaks 6 services at once, so on-call engineers got 6 incidents for one cause.
First guess: group by time window. Anything within 5 minutes is one incident. That merged unrelated problems and made it worse.
What worked: group by the most recent change. Every alert gets linked to the last deploy, config edit or flag flip before it fired.
Trade-off: if nothing changed, we fall back to grouping by service. That's fine. Those incidents are rare and usually real.
Takeaway for anyone building alerting: the cause is usually a change, not a service. Group by what changed. Full write-up on our changelog.
Notice what's missing: no intro post, no "1/" counting, no "let that sink in." Each post moves the story forward.
Writing tips that keep people reading
- One idea per post. If a post has "and also", split it or cut half.
- Short lines. Break long posts into two or three lines. Walls of text get skipped.
- Show, don't describe. A screenshot of the diff, the graph or the error message does more than a paragraph about it.
- Use code sparingly. A short snippet in a screenshot reads better than code typed into a post.
- Keep the struggle. The wrong guess is often the most relatable part. Don't polish it out.
- Put the link last. Or in a reply. Lead with value, not a click.
- Cut the last post you wrote. It is often a summary of what you already said.
After you post
Stay around for a while and reply to people. Questions in the replies often tell you what your next thread should be. If one post in the thread got more attention than the rest, that's a sign it could have been the hook, so note it for next time.
For launch day specifically, there's a separate structure in how to write a launch thread.
How Loudcode helps
The hardest part of a thread is remembering the details: the wrong guess, the trade-off, the moment it clicked. Loudcode reads your GitHub commits, pull requests and releases, so the story is already there when you sit down to write. Ask for a thread from the dashboard, or say "turn this week's work into a thread" from Claude Code, Cursor or another editor through MCP. It drafts in your Voice & tone settings, and nothing posts until you approve it.