I’ve recently upgraded some of the hardware I use for work and leisure, so it’s a good time to refresh my list of tech writing gear. At the same time, after working as a documentation engineer, I also picked up new favorite tools, especially AI-powered ones. Some I already use at work, while others I keep for personal projects. Let me tell you of some of the recent additions to my personal inventory and why I think they’re making me more productive.

In what is tantamount to a vulgar display of power, social media has been flooded with AI-generated images that mimic the style of Hayao Miyazaki’s anime. Something similar happens daily with tech writing, folks happily throwing context at LLMs and thinking they can vibe write outstanding docs out of them, perhaps even surpassing human writers. Well, it’s time to draw a line. Don’t let AI influencers studioghiblify your work as if it were a matter of processing text.

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.