Content2 min read

One post, one idea

The most common fixable problem in developer writing is not length or tone. It is that the post is trying to do three things.

Here is a post that fails:

Launched the new version today. Learned a lot about pricing along the way. Also AI agents are changing how I build. Here's my stack. Founders should never give up.

Five ideas. The reader cannot summarise it, so they retain none of it.

Here is a post that works:

I learned something uncomfortable from this launch. People did not care about the feature. They cared about the thirty seconds it saved them.

One idea. One payoff. A reader could repeat it to someone else, which is the actual bar.

The test

Can the reader summarise the post in one sentence?

If yes, it has one idea. If they would need two sentences, it has two ideas and should be two posts.

This is not a length rule. A 300 word post can carry one idea and a 40 word post can fumble two.

Why it happens

You did several things. They all feel connected because you did them in the same week, in the same project, with the same context in your head.

The reader has none of that context. What reads as a coherent arc to you reads as a list to them.

The fix is separating the doing from the writing. Work is continuous. Posts are discrete. One does not map onto the other.

Two ideas is a gift, not a problem

When you find a post with two ideas, you have two posts. That is a good position. Most people's difficulty is finding things to write about, and here you have accidentally found two.

Split them, publish one now and one in a few days. Both are stronger for the room.

The instinct to combine comes from feeling like each idea is not enough on its own. Usually it is. Posts are shorter than people think.

Where the rule bites hardest

On X, it is structural. 280 characters holds one thought. Two ideas means both get a fragment.

On LinkedIn, the room to include more is exactly the trap. You can fit three ideas. The post will be worse for it, and the extra length disguises the problem.

In threads, it applies to the thread rather than each post. A thread is one idea developed across several posts, not several ideas queued up.

The upstream version

This applies before writing, at the point where you decide what a post is about.

We hit this building Noomachy DevTracker. The system groups related commits into a story, and a story becomes a post. Early on it produced a story containing forty commits spanning six unrelated subsystems.

No writing technique saves that. If you hand a writer forty unrelated facts and ask for a focused post, you get vagueness, because vagueness is the only thing true of all forty.

The fix was upstream: split oversized groups along the boundaries the author had already declared. One idea per post had to be enforced at the point the material was assembled, not at the point it was written.

The same is true when you are doing it by hand. Decide what the post is about before you start writing, and write only that.

writinglinkedinxediting

Keep reading