The article is often the least interesting thing that happens after you publish.
Not always. But more often than we're willing to admit.
I saw this comment recently and couldn't unsee it:
"Real war stories have specifics — the exact error, the wrong turn you took first, the fix that seemed obvious in retrospect. Generated stuff stays vague. Honestly the comments on that post became better content than the post itself."
That last sentence describes something we rarely say out loud.
What actually happens when you write with real specifics
Not tips. Not frameworks. The actual error. The wrong turn. The fix you missed for three hours.
That level of detail does something polished content almost never does: it makes other builders recognize themselves instantly.
And recognition doesn't produce passive reading. It produces contribution.
The article doesn't contain the knowledge. It releases it.
Publishing without the discussion is publishing an incomplete object.
The post and the thread aren't two separate things. One makes the other possible. Strip the comments and you lose half the object. Strip the post and the comments have no spine.
We treat articles as finished products and comments as disposable noise. So we archive the post and let the discussion rot.
Which means we're systematically preserving the least interesting half of the knowledge.
We optimize for authorship. We don't preserve conversations.
Maybe we didn't even want to.
Where did the real fix appear — in the article or in the replies?
Link a post where the comments mattered more than the text.
What's the best technical insight you found buried three levels deep in a thread — that no article ever captured?
If you think the article still matters more than the discussion, I'd genuinely like to hear why — because I'm no longer sure.
Top comments (28)
From a security / analytics perspective, I’ve started to think of articles the same way we think about systems: the published post is just the attack surface — the real activity happens in the interaction layer.
Some of the most valuable things I’ve learned here never came from the article itself, but from someone correcting an assumption three replies deep, or sharing the actual failure behind the polished write-up.
Ironically, that’s also where authenticity shows up. Generated or optimized content tends to stop at publication. Real experience keeps evolving in the comments because reality is messy.
In that sense, the article isn’t the content , it’s the handshake that allows knowledge exchange to start.
The “attack surface” analogy is spot on.
It also highlights something subtle: polished articles tend to present a resolved reality, while the discussion layer exposes the unresolved one — the wrong assumptions, the edge cases, the things that only show up when multiple people compare notes.
That messy layer is probably closer to how engineering knowledge actually forms in practice.
Thinking about it — what’s something you’ve learned in a thread that you’ve never seen captured properly in an article?
Honestly? The biggest thing I’ve learned from threads that articles miss is that systems don’t fail where documentation predicts.... they fail where humans adapt.
In discussions, someone eventually reveals the workaround, the shortcut, or the “temporary” decision that quietly became permanent.
Articles describe intended design.
Threads expose operational reality.
Most breaches I’ve studied make perfect sense only after reading engineers talk candidly in comment chains , not in postmortems, but in those informal exchanges where people admit friction, assumptions, and tradeoffs.
That layer almost never makes it into the official narrative, but it’s where engineering knowledge actually forms.
Of course, this is just my current perspective and I’ve learned my opinions tend to evolve the more conversations like this happen.
That distinction might be the heart of it.
Intended design is clean, stable, and publishable. Operational reality is adaptive, negotiated, and constantly shifting — which makes it harder to capture in a finished piece.
I wonder if part of the discomfort comes from the fact that operational reality doesn’t belong to a single author. It only emerges when multiple engineers compare notes.
Maybe that’s why it shows up in threads first.
🤯
Yes, exactly 🙂 For me, the comments are at least half — if not more — of the value of an article, especially here on DEV! I have the fondest memories of the discussions under my jQuery post and the ones from the JS WTF series — that’s where the real magic happens 😄
That's a great example — jQuery and JS WTF are exactly the kind of posts where the comments become part of the lore. People bring their own war stories, edge cases, things that only make sense if you've been there.
I wonder if that's actually what makes a post "memorable" over time — not the article itself, but the conversation it unlocked.
This assumes all writing serves the same function. Some writing is designed to be a catalyst for conversation. Some is designed to be a closed, precise transmission of a framework or idea. Treating the second like a failure mode of the first is just a category error dressed up as insight.
That’s a fair distinction. Some writing is absolutely meant to be self-contained and precise rather than conversational.
I guess what I’m circling around is slightly different: even when writing aims to be closed and complete, the operational understanding of it often continues evolving once other practitioners interact with it.
Not as a failure of the original piece — more as a second layer that only appears when multiple people start testing the idea against reality.
This is really insightful and lines up with the past booms/busts in my past. What made you realize this? And is there any tips you have for writing in that detailed style without losing narrative form?
I started noticing it when I bookmarked articles but only remembered something I’d read in the replies. That pattern repeated enough times to bother me.
For writing, I suspect it’s less about adding detail and more about not abstracting too early — keeping the wrong turn in the story instead of cleaning it up.
Where does that happen most for you — docs, blog posts, Stack Overflow threads?
It really only happened once in Medium. That was where I started writing in 2018/19. I had one really specific article that amounted to an instruction manual, and it blew up (25k reads), sandwiched in between a sea of loose and vague theoretical conversations that didn't even garner 1k reads combined.
You just published the proof of concept for everything I was trying to say. 25k vs 11 — that gap is the whole argument. And your diagnosis is exactly right: you switched from their perspective to yours.
One thing worth noting though: you wrote about the failure honestly, and this post is already more interesting than the follow-up that got 11 reads. The war story is back.
Thanks man. I really like your perspective. Idk if you're a product guy as well, but if you are would you take a look at my most recent post? Curious if it's relevant and what you would have to say.
Thanks man. I really like your perspective. Idk if you're a product guy as well, but if you are would you take a look at my most recent post? Curious if it's relevant and what you would have to say.
Just read it — and honestly it deserves its own comment thread. You diagnosed the problem better than most people do in hindsight: you stopped writing about their problem and started writing about your solution. That shift is subtle but it kills reach every time.
The good news: this post is already the correction. You're back to writing about the failure, not the feature.
Thanks Pascal
I think it depends on the article's purpose. I used to write a lot of articles a few years ago. Most of it was intended as a guide, so comments for me were not valuable at all; they were just a way to clarify things or extend a poorly described process. Eventually, I came across sites like Medium and learned that comments were a way to engage with the community, which made them very important.
That's a fair distinction — a setup guide for nginx doesn't need a discussion, it needs to be accurate. But I'd push back slightly: even the best guide usually has a comment somewhere that says "this breaks on Ubuntu 22.04 if you have X installed." That comment is part of the guide now, whether we treat it that way or not.
The question is whether we're building for the 90% who follow the steps cleanly, or the 10% who hit the edge case at 3am.
That's a very good point.
Few people read my articles and even less comment them, so I am out of this equation.
That might actually be the best position to write from. The 3am debugging post doesn't need a crowd to matter — it needs one person who's had the exact same problem to find it at the right moment.
Three readers who recognize themselves beat ten thousand who scroll past.
I agree Pascal, this is framed nicely. The discussion adds a multitude shared experiences into the mix which in turn help validate and/or spark new discussions and ideas. I love this idea of shared learning!
Thanks Julien. "Shared learning" is the right frame — but I'm curious whether you've experienced it more in comment threads, or elsewhere? Forums, Slack channels, GitHub issues?
All the above, I would say!
That's probably the honest answer — and also why it's so hard to archive. It's everywhere and nowhere at the same time.
I’m starting to suspect many of us bookmarked articles but actually learned from the replies.
Curious how common that is among people who’ve been building for a while.
You're right