Demoralized by the advent of LLMs, I see tech writing communities break ranks and flee. In a world where coders who write seem to muster more respect than writers who code, the response from tech writers to the challenges posed by the intersection of automation, multichannel delivery, and docs-as-code is weak, if not absent. Conferences and blogs mostly focus on soothing anxiety and perfecting praxis. Nothing wrong with that, of course, except that it’s an intellectual dead end.

The part of my brain that rages against injustice stirs like a slumbering dragon when I read the words “Native English”. As a speaker of English as a second language, I find native to be a rather inadequate, if lazy, choice as an attribute meant to describe linguistic proficiency. You’re born with eyes, but that doesn’t automatically make you a competent watcher; you acquire a language, but that doesn’t automatically turn you into a competent writer.

We go to great lengths to get the information we need. We often interview unwilling participants. We nurture networks of informants. We write so that our audiences can understand. We simplify the complex. We like getting to the core of things. We love truth. We are powered by deep curiosity. We hunger for clarity and meaning and impact. We power through weeks full of deadlines, chasing product news, because without our reporting, most products wouldn’t thrive; some wouldn’t even exist.

This past weekend I’ve been experimenting with AI-assisted coding to port basic docs-as-code elements to old operating systems and platforms, such as the venerable Intel 386. While this might strike you as a bizarre display of futility, I find this sort of retrocomputing exercise to be quite beneficial, if not enlightening. Something just clicks when you stop and walk backwards.

Writing for LLMs is the new SEO obsession. Not a day passes without seeing some question popping up in tech writing communities about how to best compose content for AI scrapers. Folks even wonder if a different style guide should be necessary, or whether tables should be avoided because they’ve seen a pull request rejected in a Microsoft repository on the silliest grounds.

I think all technical writers, at some point or another, feel the urge to base their work on something more systematic than “it’s just the way folks documented stuff since forever”. Toolkits and frameworks provide content types, which is immensely valuable when you know what you want to write, but starting from there is like buying a hammer without knowing that half of the work you’ll do is turning screws. As I find the lack of deeper conversation around this topic rather unsettling, I decided to contribute some verses.

For the first time since I started this blog, I’m writing some predictions on software technical writing for next year. Not because I think they’ll be accurate—they never are—but because the exercise reveals what we’re concerned about and what we hope to tackle. Predictions are to-do lists in disguise: they highlight challenges we’re determined to overcome. Plus, they’re fun to write. So here are my predictions for 2025, knowing I’ll enjoy being proven wrong.

I’m a terrible user of documentation. I tend to consume docs in a hurry, reading diagonally, Control+Fing my way to things. I generally mistreat the interface of docs until I obtain something resembling an answer. I do this because I’ve little time and I need to fix issues fast. I love examples I can copy and paste. I’ve little patience for verbose documentation and even less for docs that look like they were written without care or skill. I’m not only bothered by inaccuracy, but also by bad style. In a way, as a user of documentation, I’m the worst nightmare of a technical writer.

Everybody loves to hate Frequently Asked Questions, or FAQs. More often than not, technical writers pale and stagger at the sight of hefty, unsorted FAQs, as if they were beholding a writhing mass of primal chaos. Others value their pragmatic qualities: FAQs, they say, lower the bar to contribution and are good fuel for LLMs and search engines. My opinion is that FAQs pose a problem only when there’s no strategy around their usage.

I recently was a guest on The Stack Overflow’s Podcast today, talking about docs (of course), the Vale prose linter, job titles, automation, LLMs, and much more. You can listen to the entire episode here or in the SO blog, or read the transcript. Getting docs closer to developers was one of my personal goals this year, and I think these kind of appearances might help. We need to be where developers are.