Your Readers Don't Care About Your Build Pipeline (I Checked the Analytics)
The Numbers That Hurt My Feelings
Last spring I did something every developer with a blog should do but most avoid: I actually audited my own analytics without flinching. I pulled two years of data from josephkhan.me and ranked every post by time-on-page and scroll depth.
The results were humbling. My most technical piece — a 3,000-word walkthrough of my static site build, complete with config snippets and a benchmark table — averaged 41 seconds on page and a 12% scroll depth. Meanwhile, a rambling 600-word post about the anxiety of rewriting my portfolio for the sixth time? Average read time over four minutes. People finished it. People shared it.
The pattern held across the entire archive. Every framework deep-dive I'd written underperformed. Every story where I admitted to screwing something up overperformed.
Why We Keep Writing Stack Posts Anyway
Here's my theory on why developer blogs keep churning out tooling content nobody reads: it's the path of least emotional resistance. Writing about your build setup is safe. There's no vulnerability in explaining how you configured your linter. You can't be wrong about your own preferences, and you can't be judged for a setup you chose.
Writing about the time you broke production on a Friday afternoon, or why you quit a job after nine months — that's exposing. It invites disagreement. It reveals that you, the person with the polished portfolio, are also somebody who once deleted the wrong database table.
But exposure is exactly what readers connect with. We're drowning in tutorials that all say the same thing because they're all generated from the same documentation. What's scarce on the internet is a specific person telling a specific true story.
The Mini-Audit: What Kept People on My Site
Since I did the work, here's the breakdown from my own traffic, in case it saves you the spreadsheet:
What worked:
- First-person failure stories, especially with specific stakes (money, deadlines, embarrassment)
- Short posts under 800 words with a clear takeaway
- Anything where I stated an actual opinion, even a mild one
- Posts I published within a day of writing them — the rough ones consistently outperformed the polished ones
What didn't:
- Framework comparisons (my React-vs-everything post is my all-time worst performer)
- 'How I set up X in 2023' posts — these age badly and get zero search traction against SEO farms
- Anything with 'comprehensive' in the title. Nobody has ever wanted a comprehensive anything.
The single biggest driver of returning visitors wasn't a topic at all. It was consistency. The months I published twice a month, my return-visitor rate roughly doubled. The months I disappeared to rework the site's architecture, it fell off a cliff.
The Uncomfortable Conclusion
I want to be careful not to overcorrect into 'tooling content is worthless.' It's not — technical writing genuinely helps people, and I've benefited enormously from other people's setup posts. But there's a difference between writing to help readers and writing to signal membership in a tribe. Most stack posts, including most of mine, were the latter. They were me saying I use the correct tools to an audience of people who use the correct tools, and we all nodded at each other and left.
The best personal sites I know — the ones I actually check for updates — all have the same thing: a voice. Not a framework, not a design system, not a perfect Lighthouse score. A person with a perspective who shows up regularly and tells the truth about what they're working on.
What I'm Doing Differently
My rule now is simple: before I publish, I ask whether a non-developer friend would find the piece at least mildly interesting. If the answer is no, it's probably a tribe-signal post, and I either kill it or rewrite it around the human element — the decision, the mistake, the deadline pressure — rather than the technology.
The stack is a footnote. Your readers came for a person. Act like one.
