How developers grow on X: write about the work, not the stack

Release notes do not travel. "v2.3.0: added support for custom headers" is read only by people who already use the thing. What travels is the experience behind the code: the three hours lost to a timezone bug, the number that dropped when you deleted a dependency, the twelve seconds it takes to show what the tool does. Those posts are read by every developer, including the ones who will never use your stack.

The common thread is that the reader can feel the post without running the code. A demo shows the result. A bug story has a villain and a reveal. A before and after has two numbers and a gap. Specifications, benchmarks without context and architecture diagrams do not travel on X because they ask the reader to do work before they get anything back.

A screen recording of the thing doing the thing, cropped tight, no intro, no cursor wandering, ideally under twenty seconds. The text above it says what you are about to see in one line and what is interesting about it in another. The link goes in the first reply. Most developers record a two-minute walkthrough; nobody watches past the first ten seconds, so make the first ten seconds the whole video.

• Record at the size people will watch it: a phone screen. Zoom the terminal or the browser so text is legible at that size.
• Cut the setup. Start the recording with the input already typed, one keystroke from the result.
• Loop-friendly endings work: the video should make sense if it starts again immediately.
• If there is no visual, a short before and after of terminal output as an image works too. The post to image tool makes a clean one.

Every developer has lost an afternoon to something absurd, and every developer wants to hear about yours. A bug story is three beats: what you saw, how long it took, what it turned out to be. The last line is the reveal, and the shorter it is the better. Do not explain the fix in the post; people who want it will ask, which is the reply you want.

Two numbers and the list of what changed. Build time, bundle size, cold start, query time, lines of code. The pull of the format is the gap between the numbers; the value is in the list, because that is what readers steal for their own projects. Keep the list honest and unglamorous. "Deleted a dependency" is more useful to readers than "re-architected the rendering pipeline".

A repository link with "check it out" is the most common developer launch and the least effective. The project needs the same treatment as the formats above: show it working, tell the story of why it exists, and give readers one specific thing to do. Launch day is also the one day a developer account should be in the replies all day, answering every question and thanking every star by name if you can.

1. 01The week before, post the problem that made you build it, as a bug story or a before and after. No mention of the project yet.
2. 02Launch day: a demo under twenty seconds, one line on what it does, one line on what it deliberately does not do, link in the first reply.
3. 03Reply to everyone. Questions, criticism, the person who found a typo in the README. Each reply keeps the post alive for another hour.
4. 04Day two: post what people asked for most and what you are going to do about it. Day three: the first contribution from someone who is not you, if there is one.
5. 05A week later: stars or installs with where they came from. Honest numbers, small or large.

Technical X rewards opinions and punishes tribes. "React is bad" gets attention and makes you a character in someone else's argument. An opinion about a specific behaviour, held with a reason, gets attention and makes people want to read your next post. The difference is whether a reasonable person on the other side could reply without defending their identity.

When a framework war arrives in your replies anyway, the moves that end it instead of feeding it are in replying to hot takes and reply examples for developers.

Your readers include developers in other stacks, designers, founders and people who last wrote code in university. Writing for them is not dumbing down. It is choosing the detail that carries the point and cutting the ones that only prove you know the subject. A backend engineer does not need your CSS specifics to feel the before and after; they need the two numbers and the one surprising cause.

• Lead with the effect (slow, broken, confusing, fast) and put the mechanism second. Readers decide to continue based on the effect.
• Use one technical term per post and make the post survive if the reader skips it.
• Numbers beat adjectives. "1.1 seconds" needs no expertise; "blazing fast" needs trust you have not earned yet.
• Cut acronyms the reader can live without. If you must use one, the sentence around it should make the meaning obvious.
• Read the post as someone who has never used your language. If a line only makes sense to insiders, it is either the one technical term you are allowed, or it goes.

1. 01Keep a scratch file open while you work. Every bug that costs more than an hour, every number that moves, every tool decision: one line in the file.
2. 02Daily, fifteen minutes in the replies of the developer accounts you follow, with a specific: the tool you used, the thing that broke, the number you saw. The method is in how to grow on X with replies.
3. 03Three or four posts a week from the scratch file, one of them with a demo or an image. Schedule them if your coding hours are not your audience's hours.
4. 04Every post with code in it: check the first line reads as a sentence, not a stack trace. If the post runs long, the character counter tells you where X will cut it.
5. 05Once a week, look at which posts got replies from people you do not know. Those formats are your formats. Do more of them. For a backlog of shapes, see post ideas for developers.