Developers have the best raw material on X and post the least of it. Every working day produces a bug with a twist, a tool that failed you, a thing you learned reading someone else's code, a fix that was one word. Those are posts. The tutorial you keep meaning to write is not, or at least not first.
Here are fourteen posts, written out in full so you can see the shape, each with a note on why it works. None of them require a code screenshot, a thread or a hot take about a framework. The details are invented for the examples; yours will be true, which is the whole point.
Why developer posts stay unread
Most developer posts fail in one of two ways. They are written for the author's exact stack, so anyone outside it scrolls past, or they are written as announcements with no story, so even people inside the stack have nothing to say back. The posts that travel do the opposite: they tell a small story anyone who has written code recognises, with one specific detail that proves it happened.
The filter: would a developer in a different language understand the feeling, and would a developer in your language learn the detail? A bug that only exists in one framework can still be a post if the story is about reading the whole error message.
Bugs and the stories behind them
A bug story with the twist at the end
Three hours on a test that failed only on CI. The cause: CI runs in UTC and the test created a date at 11:30pm local. I will never trust a date again.
- Why it works:
- Everyone has lost an afternoon to time zones. The twist is small enough to be believable and the last line is the shared feeling.
The one-line fix
Fix: added `await`. Time to find it: a full afternoon. Every senior engineer I know has this story. Mine was today.
- Why it works:
- The ratio of fix size to time lost is the post. Admitting it today, not years ago, is what makes people reply with theirs.
A bug a user found
A user reported the app crashes when their name contains an apostrophe. It is 2026. I shipped an O'Brien bug. Fixed, and added a test with every name from my family.
- Why it works:
- A classic bug, owned with humour, and a concrete fix. Readers learn something and like you more.
Debugging advice taken from a bug
Debugging rule I relearned today: read the whole error message. The answer was on line two. I spent an hour on line one.
- Why it works:
- The advice is old; the proof is fresh. Advice attached to the moment you needed it does not read as a lecture.
Tools, opinions and being wrong
Opinions about tools are the most common developer post and the most skipped, because they are usually about a brand rather than about a problem. Anchor the opinion to the thing that bit you and it becomes a post people can answer with their own scar.
A tool opinion with the problem attached
I don't need a faster bundler. I need a bundler whose error messages name the file I actually edited. Speed is solved. Clarity is not.
- Why it works:
- The contrast between what the industry optimises and what you needed this week is a reliable shape, and it names no vendor.
I was wrong about
I was wrong about TypeScript. Said it was ceremony for small projects. Then spent a weekend tracing undefined through a 400-line script. Types are documentation that argues back.
- Why it works:
- A public reversal with the incident that caused it. The last line is a definition people will quote.
Pick a side, honestly
Monorepo for a two-person team. Give me one real reason to split it. Not a hypothetical, a thing that bit you.
- Why it works:
- You name your current choice and ask for evidence, not opinions. The replies are useful to everyone making the same call.
A default you changed
Changed one default this week: new projects start with a logger instead of console.log. Felt like overkill on day one. Saved me on day three.
- Why it works:
- Small, adoptable and told with a timeline. People reply with the default they changed.
Demos, before and after, and small ships
A demo described in words
Shipped: paste a URL into the editor and it unfurls into a card, title and image, in about 300ms. The hard part was not the fetch. It was the 14 sites that return the wrong content type.
- Why it works:
- The feature is described by what the user sees and timed. The second line is the part only a developer would know, and that is why developers reply.
Before and after with the cause
Before: the dashboard loaded in 4.2 seconds. After: 0.9. The change: one index on the column we filter by on every request. I had the slow query log off for a year.
- Why it works:
- Two numbers, one cause, one confession. The confession is what keeps it from being a brag.
A small ship, defended
Small ship today: keyboard shortcuts for the three things people do most. Took two hours. Two people have already said it is the reason they will stay.
- Why it works:
- Small work with a disproportionate result. It gives other developers permission to ship small things too.
Learning in public
Something learned reading source
Read the source of the date library I have used for five years. The function I call most is 11 lines and handles a case I did not know existed. Read the source. Earlier.
- Why it works:
- A habit, demonstrated rather than recommended. The specific function and line count make it real.
Explaining something to a non-developer
Explained caching to a designer today. "It is a sticky note on the fridge so you do not have to open the fridge." She got it in one. I am keeping the sticky note.
- Why it works:
- Analogies that worked on a real person are useful to everyone who has to explain their work. Non-developers share these too.
A question for developers who changed roles
Developers who switched from writing code to running a product: what do you miss, and what surprised you by not missing?
- Why it works:
- A narrow group, a concrete moment and a two-sided answer. The replies are a resource for anyone considering the switch.
From your commit log to a post
- 01At the end of the day, read your commit messages and your browser history. Both are a list of problems you had.
- 02Pick the one that cost the most time relative to the size of the fix. That ratio is the story.
- 03Write what happened in order: the symptom, how long, the cause, the fix. Plain words, no jargon you would not say aloud.
- 04Add the one sentence you would tell a teammate afterwards. That is the last line.
- 05Remove any line that explains the technology to someone who does not use it. Let the story carry them instead.
- 06Post it, then reply to three other developers' posts; the reply examples for developers show how to be useful without being a know-it-all.
Posts that read as noise
Do
- The bug, the cost and the cause, in that order.
- Opinions about problems you had, not about brands.
- Small ships with their small, real results.
Don't
- "Just shipped v2.3.1" with no story attached. Nobody outside the project knows what changed.
- Framework wars. Even when you are right, the people who agree already follow you and the people who do not will not be convinced.
- Screenshots of code with no text explaining what the reader is looking at.
The developers who grow on X are rarely the ones with the best code. They are the ones who notice what happened at their desk today and write it down for the person who will hit the same thing tomorrow. The developer growth guide covers the rest: replies, launches and staying out of the arguments.
BuzzyX · X growth workspace
Grow on X with posts that sound like you.
Compose in your voice, schedule the week, find posts worth replying to and read real analytics from the X API. $29/mo after the trial, everything included.
Frequently
asked questions
Something else on your mind? Get in touch.
Do I need to post code to grow as a developer on X?
No. Most of the posts that travel are stories about code, not code itself. A screenshot helps when a snippet is the point, but the text has to carry the post on its own because many people never open the image.
Should I post about my stack or stay general?
Post about your stack through stories anyone can follow. A bug in one framework is a post for everyone if the story is about reading the error message or trusting a default. Pure framework advocacy only reaches people already using it.
Is it okay to post small ships every day?
Yes, if each one says what changed for a user and what it cost or taught. A list of version numbers is noise; a two-hour fix that kept two customers is a post.
How do I share a bug without making my product look broken?
Own it, name the fix and say what you added so it cannot happen again. Readers trust products whose developers talk about bugs more than products that claim not to have any.
What about threads explaining a concept?
Write them once your single posts reliably get replies. A long thread to a small audience is a lot of work for little reach. Until then, one concept per post, with the analogy that worked on a real person.