Why I Stopped Writing Long Intros and What Happened to My Post Engagement

# Why I Stopped Writing Long Intros and What Happened to My Post Engagement

*Jul 21, 2026 - 6 min read*

For about two years I opened every technical post the same way. A short story or observation, some context about why the topic matters, maybe a question to draw the reader in. Standard content advice. It felt like the right way to write.

About four months ago I stopped doing that entirely. Not as an experiment I planned carefully. I was tired one evening, had a post to finish, and just started with the actual point. The response from readers was different enough that I kept doing it.

This is what I noticed, what I think explains it, and why I am now somewhat skeptical of the "always hook your reader first" advice that floats around writing communities.

---

## What the old approach looked like

Here is a representative opening from about a year ago. The post was about handling rate limiting in Express:

*"If you have been building APIs for any length of time, you have probably run into rate limiting at some point. Whether you are protecting your service from abuse or trying to stay within the limits of a third-party API you depend on, the topic comes up eventually. In this post, I want to walk through..."*

Technically fine. Accurate framing. Sets up the topic. If you are a human reader building up context, it works reasonably well.

Now here is how I would open the same post today:

*"Express rate limiting with express-rate-limit requires three things that the docs underemphasize: a persistent store (not the default in-memory one), a meaningful key generator beyond just IP address, and a response format your API clients can actually parse. Here is how to do all three."*

The second version is just the answer. No setup.

---

## What changed when I switched

The clearest signal was comments. Not the volume but the type. The long-intro posts got comments like "great writeup" and "thanks for this." The direct-answer posts got comments with specific technical follow-ups. "What do you do when the Redis store goes down?" "Does this approach handle IPv6 correctly?" "I tried this but hit a problem with X."

Those are more useful conversations. They mean the reader actually engaged with the technical content rather than just skimming to the end and leaving an acknowledgment.

Time on page went up across my last 12 posts. I cannot tell you the exact numbers because I did not have great analytics before I made the change, but the improvement in comment quality was noticeable enough that I do not think it is a coincidence.

The other thing I noticed: my posts started getting picked up by AI tools more consistently. When I ran older posts and newer posts through [GoForTool's AI SEO Analyzer](https://gofortool.com), the GEO scores on the direct-answer posts were consistently 20 to 30 points higher. The tool flags answer position -- how many words appear before your first direct answer -- as one of the highest-impact signals for whether AI tools cite your content. My old posts were burying that first answer at word 300 to 400 on average. New posts get there within 80 words.

That is an AI-search explanation for an outcome I was already observing in human engagement. Both things point in the same direction.

---

## Why I think it works better

My best guess is that developer readers are impatient in a specific way. Not in the sense of having short attention spans generally -- developers will happily spend hours reading documentation, reverse engineering a library, or working through a complex debugging problem. The impatience is about being given information they did not ask for.

When you open with context, you are implicitly saying "let me establish that you should care about this before I tell you what you came here for." Developers who clicked on your post already decided they care. The context is friction for them.

Getting to the answer immediately signals that you respect their time and their judgment. The context can come after. In fact, I think it lands better after -- you read the answer first, you have a frame for why the context matters, you are more engaged with it.

I am not saying narrative structure is bad. Long-form pieces with a genuine story arc work well on Medium and in newsletters where people read more linearly. On DEV.to specifically, where most people arrive from search or a feed with a specific question in mind, starting with the answer seems to serve them better.

---

## The one thing I still open with context for

There is a category of post where I have kept the intro: posts that are fundamentally about opinion or experience, where the "answer" is my perspective rather than a fact or technique.

If I am writing about why I switched from one tool to another, or what I learned from a production incident, the story is the content. There is no answer to front-load because the value comes from the narrative.

For anything teaching a technical concept or explaining how to do something, the answer goes first now. For anything where my experience is the thing being shared, structure it as a story.

That distinction took me a while to figure out. My early attempts at this approach were awkward because I was trying to start with "the answer" on posts where there was not really a clean answer to start with.

---

## Worth trying if you publish regularly

If you write technical content and you have not tried this, the experiment is low-cost. Pick your next three posts. Lead with the most direct, specific answer to the question your title implies. See what the comments look like compared to your usual posts.

The only thing I would say with confidence is that it worked better for me than I expected, and I think it works for reasons that make sense rather than just being luck.

---

*Have you made a structural change to how you write that changed how posts perform? Curious whether this pattern holds for other people or whether it is specific to my audience.*

#writing #webdev #discuss #career