I recently read an article by @miracool asking the question: do people still genuinely care about technical articles? My answer is nuanced: yes, but not everyone.
Beyond that question, there is another, more fundamental one: who do we choose to write for today?
A Long-Term Trajectory
I've been writing technical articles since 2010-2011. Some still exist in the Wayback Machine archives — like this one, dated December 2011, about a MySQL limitation that barely makes sense to address today. My blog has been running since 2016. Since August 2025, I've also been writing in English.
I've never published at an industrial pace. I wrote when I had something to clarify, document, or share.
Over this period, one observation stands out: some articles disappear within a few months, while others continue to be read years later. Not massively. But steadily. By readers who arrive through a specific search, who actually read, and who sometimes write back.
It's almost always the same types of texts that survive: those that document an approach, a technical decision, a real problem encountered over time. Highly specific tutorials, on the other hand, meet an immediate need and then logically fade away.
This isn't a theory. It's an observation built over time.
How We Consume Technical Knowledge Today
Fifteen or twenty years ago, you bought a technical book and used it for years. I bought the PHP5 Bible in the mid-2000s. I relied on it for nearly three years. But back then, you couldn't find nearly as many up-to-date resources online as quickly as you can now.
Today, access to technical knowledge is immediate. Resources are digital, abundant, constantly updated. Tools have simplified many deployments. Answers are available within seconds.
This isn't better or worse. It's a different way of learning and working. I consume differently myself.
But this evolution has a direct consequence: the lifespan of technical content has shortened. And that naturally changes the way we write.
Technical Articles Haven't Disappeared — They've Evolved
We need to distinguish between two types of technical articles.
There's daily news: announcements, releases, updates. A new version of PostgreSQL. New MySQL features. A new project from an Apache incubator. These articles are widely read. They meet a need for technical current events. It's information.
And there's the in-depth magazine: detailed articles, experience reports, carefully constructed reflections. The National Geographic of tech. These articles reach a smaller but loyal audience. Readers who are genuinely interested.
This distinction between technical news and substantive reflection isn't new. There have always been texts with no clear thinking behind them. Lists like "Top 5 WordPress Themes for 2026" or "10 Best Plugins for 2025" that enumerate tools with their pros and cons but offer no real analysis have always existed. Humans are perfectly capable of producing empty content. Artificial intelligence didn't create this problem — it simply amplified the volume.
What remains rare are articles that go deeper. That not only show strengths and weaknesses but explain use cases, contexts, the reasoning behind choices. Those require structured thinking. As Boileau once said: what is well conceived is clearly stated.
To illustrate this concretely, I submitted the same prompt to Gemini and ChatGPT: "write a 1500-word article on 'who do we choose to write a technical article for?'". Both produced correct, well-structured texts. ChatGPT even found some interesting angles — the translator-reader, the machine as an unexpected recipient. But both shared the same fundamental limitation: zero lived experience, zero concrete data, zero personal trajectory. Texts that are true for everyone, and therefore belong to no one.
That's not a flaw in the tool. It's the direct consequence of a prompt with no real thinking behind it.
AI produces articles, but left undirected, it doesn't produce substantive ones. You can ask it to write a tutorial on any technical subject and get a text that looks correct on the surface but is empty of genuine reflection.
For my part, I use AI to structure my articles, to rephrase, to validate hypotheses. But I don't give it a generic prompt like "write a 1500-word article on who we choose to write a technical article for." The thinking that feeds the text comes from my research, my experience, my history.
And the drafts the AI produces — all of them, not just the first — are then reread, corrected, and reworked to match my own voice. This article itself is the result of a conversation with Claude and ChatGPT. But once that conversation was over, I reread it. I rewrote entire sections. I amended others. The work is greatly simplified by AI, but it isn't directly generated writing. It's augmented writing. The difference is essential.
Both types of articles still exist. But they don't address the same audience or the same timeframe.
What has changed is that the sheer mass of available information has paradoxically made in-depth articles more substantive, not less relevant. Since the basic tutorial is everywhere, what remains to be written is the reasoning behind it.
Why I No Longer Write Tutorials
For a long time, I wrote very detailed tutorials. Complete guides, designed to walk a reader from start to finish.
Today, I don't write them anymore.
Not because tutorials have become useless. They remain essential, particularly for beginners or specific use cases. But they are now produced faster and often better by others: official documentation, communities, interactive tools, technical assistants.
A very precise tutorial also becomes obsolete faster. Versions change, methods evolve, abstractions multiply. In many cases, a quick search is enough to solve the problem.
So it's not the tutorial that's disappearing. It's simply that I've stopped making it the core of my writing.
What Writing Still Allows
Technical writing retains a specific quality.
It allows for measured reflection. Rereading. Precise citation. Continuity over time. A text can be found again, annotated, reused, reread years later.
A video informs. An instant response helps solve a problem. But a structured text allows you to follow a line of reasoning and return to it.
This isn't about the superiority of formats. It's about function. Writing remains particularly well-suited for documenting a technical experience over time.
What Holds Its Value
Over time, I've shifted my center of gravity.
I'm less focused on explaining exactly how to do something. Others do that very well and very quickly. I try instead to document an approach, a technical choice, a feedback report, a thought process, what worked and what didn't.
This type of text doesn't meet an immediate need. It speaks to those who want to understand a line of reasoning, not just execute a procedure.
It probably reaches fewer people. But it lasts longer.
A Different Audience
This audience exists. I know because some articles continue to be read long after publication. They show up in stats. They're found through specific searches. Sometimes they prompt a message months or years later.
I've had articles that were read far more widely. Between 2017 and 2019, an article about Twenty Seventeen, the WordPress theme, generated 20 to 25,000 reads and over a hundred comments. I also see what viral articles on dev.to look like: thousands of likes, hundreds of comments.
That's not what I'm talking about.
Writing in English hasn't given me a massive audience. Between August 2025 and today, 25 articles have generated around 14,000 views. Modest numbers.
But it's a different audience. Switching to English wasn't a strategy. It came naturally. My technical experience is international. And this English-speaking audience — partly made up of people who write themselves, and above all readers interested in this kind of reflection — aligns more closely with who I am.
I'm not addressing a majority. I'm addressing people who build, who think, who look for experience reports rather than immediate answers.
Why Write Publicly?
If this audience is limited, why keep publishing? Why not simply keep private notes?
Because public writing changes the nature of reflection. It forces you to clarify. To structure. To stand behind what you write. And sometimes, it creates a deferred conversation with people you will never meet directly.
Publishing an in-depth technical article is contributing to a shared space for reflection. However modest. However quiet.
An Assumed Choice
Writing substantive technical articles today isn't the fastest way to gain visibility. It's not the most efficient for producing content at volume either.
But it's the approach that best matches the way I work and think.
I write to document approaches and technical trajectories. For a handful of interested readers. For continuity over time.
There's nothing heroic about this choice. It's simply consistent with how my practice has evolved.
Side note: this article is written in WordPress and published directly to dev.to via the API — I covered how that works in a previous article.
Continuing
Technical articles haven't disappeared. Neither has their audience. It's simply different: less massive, more attentive.
Writing today for that audience is a choice.
The question, for me, isn't whether people still care about technical articles. They do. Or at least, some do.
My question is more ethical: do we still want to write for those who truly care?
Top comments (29)
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.