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 (11)
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.
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.
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.
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.