Who Are We Still Writing Technical Articles For?

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

title: Who Are We Still Writing Technical Articles For? published: true description: "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" tags: career, discuss, productivity, writing cover_image: "https://devto.tsw.ovh/wp-content/uploads/2026/02/jay_t-writing-7901174_1280.jpg"

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?