I recently read an article by @miracool asking the question: do people still genuinely care about technical articles? My answer is nuanced: yes, bu...
For further actions, you may consider blocking this person and/or reporting abuse
As usual, a very thought-provoking post. For me, writing is also a catalyst for learning. There used to be a saying: “if you want to understand something, write a book about it.” Today we could say: write an article about it.
You always end up double-checking things, reading more, connecting dots — and in the end, readers gain at least as much from it as I do 🙂
Thanks, Sylwia.
I feel exactly the same — writing is often how I test whether I truly understand something or just think I do.
What changes today is that quick answers are easy to get, but real understanding still requires that slower process of connecting dots. Writing remains one of the best ways to do that.
Couldn’t agree more. Writing articles or doing workshops/presentations are hands down the best way to learn any topic thoroughly.
This is so true Pascal, because rarely do people actually sit to read tutorials these days. I would rather read a documentation on a particular topic I have interests in, to hear from the author what worked & what did not work for them rather than a tutorial. Documentation always wins :)
Thanks Maame. I think what you're calling 'documentation' here is really experience reports — 'what worked & what didn't' is exactly that. It's different from traditional technical documentation (which is still necessary) but it's also different from tutorials.
The tutorial tells you the steps. The experience report tells you why those steps, what failed along the way, and what you'd do differently next time. That context is what makes it worth reading.
Rightly so Pascal, with the experience report as you put it, people who read it would be able to agree with you more and also know that if A or B doesn't work in something, it doesn't make them less of a developer (because other people experience it). Always great pointers from you!
That's a good point I hadn't made explicit — sharing what didn't work isn't just about documentation, it's also about normalizing failure as part of the process. If someone else struggled with the same thing, it's not just you.
The 'what failed and why' posts serve two purposes: they help people solve problems, and they remind them that struggling doesn't mean incompetence. Both matter.
Exactly
I've been thinking about this a lot lately, and it's like you're speaking my language. I mean, with the internet at our fingertips, people expect answers now, not later. It's refreshing to see someone writing for the sake of writing, rather than just for clicks.
A truly intriguing post Pascal!!
Thanks, Aryan. Small clarification though — it's not quite 'writing for the sake of writing.' It's more like: writing because something is worth documenting, even if only a handful of people will find it useful.
The difference is subtle but important. I'm not against reach or clicks — I'm just no longer optimizing for them at the expense of substance. If 10 people find what they need, that's better than 10,000 who skim and forget.
True words Pascal.
honestly I write for the same 3 people who actually build things and wont have it polished. the SEO-optimized tutorial era is kind of dying - nobody needs another how to set up react router post. but the here is what broke at 3am and why articles? still irreplaceable. I started writing more about my own project failures and the comments got way more interesting. writing for one specific reader who would genuinely relate beats optimizing for 10,000 generic ones
Writing for one specific reader who would genuinely relate beats optimizing for 10,000 generic ones' — that's the entire point in one sentence.
What strikes me is that you and @leejackson both independently mentioned the '3am debugging' scenario. It's apparently become the litmus test for real experience vs generated content. If you haven't been there at 3am staring at logs, you can't write that article — no matter how good your AI prompt is.
And 'the comments got way more interesting' when you shifted focus — that tracks. Generic tutorials get generic reactions or none at all. Specific failures spark actual conversations because people recognize themselves in the situation.
Three readers who actually build things is a better audience than 10,000 who are just browsing.
the 3am debugging test is real. 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’s a great way to put it.
Real “war stories” have texture — the wrong assumptions, the dead ends, the moment things finally click. That’s the part no generated content can convincingly reproduce because it comes from lived friction.
And I agree about the comments sometimes becoming better than the post itself. When people start sharing their own failures and fixes, it turns a static article into something closer to a collective field report.
This is nicely put together; writing for those who care requires that an author understand their audience and their need, which comes in handy to provide quality content.
Thanks for reading. You're right — understanding your audience means understanding your subject deeply enough to know what actually matters to them. That's where surface-level content falls apart.
The question "who is this for?" is one most writers don't ask until after they've written several pieces that didn't land.
My answer: write for the version of yourself from 18 months ago. That person has enough context to follow along and enough distance from your current knowledge to need the explanation. They're specific, they're real, and you know exactly what they would have found valuable.
The trap is writing for maximum audience — "beginners" is too vague to write well for. "Junior developers who know JavaScript but haven't worked with databases yet" is a person you can actually help.
'Write for the version of yourself from 18 months ago' — that's a remarkably practical heuristic. Specific enough to be useful, recent enough to remember what you actually struggled with.
And your point about 'beginners' being too vague is critical. When people say they're writing for beginners, they often end up writing for no one in particular. 'Junior developers who know JavaScript but haven't worked with databases yet' is a real person with a real gap you can address.
The 18-month distance also gives you something else: you've had time to see which solutions actually held up and which ones didn't. You're not just documenting what worked yesterday — you're documenting what survived.
This might be the most actionable definition of 'audience' I've seen in a while.
Really resonated with the distinction between "daily news" and "in-depth magazine" content. I've noticed the same pattern in my own reading habits — I skim release announcements, but I'll actually bookmark and re-read posts where someone documents a real architectural decision or explains why they chose approach A over B.
There's a third audience nobody mentioned yet: your future teammates. I've lost count of how many times I've onboarded someone onto a project and the most useful resource wasn't the README or the docs, it was a blog post one of us wrote 2 years ago explaining why we structured the auth system the way we did. That context is almost impossible to reconstruct after the fact.
Your point about "augmented writing" vs "generated writing" is key. The best use of AI in writing (for me at least) is when I have the ideas but I'm struggling to organize them. It's a structuring tool, not a thinking tool. The thinking still has to come from somewhere real.
'Your future teammates' — that's a perspective I touched on in the 'writing for the team' section, but your auth system example makes it concrete. The README tells them what exists. The blog post from 2 years ago tells them why it exists that way. That context is irreplaceable.
And you're right that it's almost impossible to reconstruct after the fact. The person who made the decision has moved on, or forgotten the constraints, or the political context that shaped the choice. The article preserves not just the solution but the reasoning.
'Structuring tool, not a thinking tool' — that's the cleanest way I've heard someone describe augmented writing. The AI helps organize what's already in your head, but it can't generate what isn't there. The thinking has to come from somewhere real.
These comments are proving the article's point in real time. People who actually build things recognizing themselves in the patterns.
Your observation about which articles survive long-term really resonates. I have noticed the same pattern — tutorials on "how to set up X" get obsoleted by the next version, but articles documenting WHY a decision was made or how a real problem was approached stay relevant for years.
The audience question is key too. I think we are increasingly writing for two readers: humans who want context and judgment calls, and AI systems that will ingest our writing as training data or retrieval context. That second audience actually makes technical writing MORE important, not less — the quality of what we put out there directly shapes the tools we all end up using.
That's a perspective I hadn't fully considered — the idea that we're now writing for both human readers and the systems that will train on or retrieve from our content. It does add weight to the argument for quality over volume.
At the same time, I'd argue the primary audience should still be human. If we start optimizing for machine readability or AI retrieval, we risk losing the voice, the nuance, the judgment calls you mentioned — the very things that make an article valuable beyond just information transfer.
But you're right: what we write today shapes the tools we'll all use tomorrow. That's both encouraging and slightly unsettling.
You're absolutely right that the primary audience should remain human — the moment we start optimizing for machines over people, we lose the very thing that makes good writing worth reading. I think the sweet spot is writing naturally for humans while being aware that it also feeds into AI training data. That awareness might nudge us toward more precision and originality, which benefits human readers too.
That's a great way to frame it. I think there's another angle too: when you write for humans with genuine respect — meaning you owe them the best quality you can deliver if they're giving you their time — the machine metrics follow naturally.
AI systems measure reception through engagement: time spent reading, conversations sparked, how often people return to an article. All of those are indirect measures of whether you actually respected your human audience.
So in a way, writing well for humans is the best way to 'write for machines' — not by optimizing for them, but by creating something worth measuring in the first place.
Your point about AI commoditizing the "How" is spot-on, and it's reshaping why I write.
I've been publishing automated content for a year now (using AI pipelines to generate and cross-post). The pieces that get engagement aren't the ones AI helps most with — they're the ones where I document a specific failure, a counterintuitive decision, or a before/after comparison from real work.
AI can write "How to set up X." Only a human who actually ran X in production at 3am can write "Why X quietly ate all our memory and what the logs actually said."
So my current answer to your question: I write for the future me who will Google the exact error message I just spent 4 hours debugging. If that audience is just one person, that's enough. The search engines will find them.
The articles with the longest shelf life in my analytics are consistently the "why this specific thing failed" posts, not the tutorials.
This is gold. The fact that you've been running AI pipelines for a year and can compare what works gives real weight to the observation.
Your distinction — 'How to set up X' vs 'Why X quietly ate all our memory' — perfectly captures it. The first is documentation. The second is experience. And only the second requires having actually been there at 3am.
'If that audience is just one person, that's enough' — that's exactly it. You're not optimizing for reach, you're optimizing for usefulness to the one person who needs exactly that answer. And the search engines reward that precision over time.
It's reassuring to hear your analytics confirm it. The 'why this failed' posts lasting longer isn't surprising, but it's good to see it measured.
This is a fantastic take on the evolution of tech writing. You’ve hit on a vital truth: AI has commoditized the "How," which makes the "Why" more valuable than ever. I love the shift away from writing fleeting, step-by-step tutorials toward documenting the kind of architectural intent and lived experience that actually lasts a career. Using AI as a "sparring partner" rather than a ghostwriter is the perfect way to maintain that human soul, ensuring the content is augmented rather than just generated. Ultimately, 14,000 views from people who actually think and build is worth far more than a million drive-by clicks—writing for those who "truly care" is how we actually preserve the tribal knowledge of our industry.
Thank you for such a thoughtful reading.
I really like how you frame it — AI commoditizing the “how” inevitably pushes us toward the “why” and the intent behind decisions. That’s probably where technical writing becomes more interesting again, and also more personal.
And yes, using AI as a sparring partner rather than a ghostwriter feels like the right balance for me. It helps refine thinking without replacing the experience behind it.