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.

A reader asked me how they’d become a Documentation Engineer, because they saw I got hired as one and felt curious about what it takes to get there. This inevitably got me thinking about job titles and the evolution of tech writing, two topics that are quite central to this blog. Let me begin with the short answer: As a tech writer you’ll have to wear many hats, but you’ll always be a technical writer. Depending on your preferences, some hats will be more comfortable than others. Docs Engineer is one of those.

I’ve been using large language models (LLMs) for a while now. They accelerate and improve my output at work, to the point that losing access to them would make me feel slightly impaired in some areas. Rather than fearing WriterBot, I’m embracing the additional capabilities it grants. At the same time, I’m extremely conscious of their limitations, which are abundant. Let me tell you how LLMs are helping me in my everyday work as a documentation engineer and where they’re unable to assist me.

I’ve recently started a new job as a documentation engineer. While my work is largely the same as that of a technical writer, the sound and semantics of my new job title gave me some pause and made me think about what it really means to be doing docs-as-code. To say that it’s about writing documentation using the same tools and methods as software developers is correct, but fails to acknowledge the full consequences of the fact. Most descriptions of docs-as-code are naive because they stop at the implications of being developers’ attachés.

I’ve recently found out about TypeSpec, a new language aimed at describing web APIs, through an interview that bears the provocative title of API Design in the Post-OpenAPI Era. Leaving aside the fact that OpenAPI is very much alive, what left me stupefied was the assertion that OpenAPI files should be “automatically generated artifacts and nothing more”. After digging a bit, I found the picture to be slightly more reassuring, but still quite representative of a world that keeps steering away from human-driven design to bury itself in curly brackets paradises.

What does it mean to fail as a technical writer? How does one get up again? How can we correct course and rekindle the fire that helped us power through rejections, layoffs, and ostracism? Is there any switch we can toggle so that folks understand what it is that we do and provide us with the resources we need in order to contribute a verse? I’ve been thinking about all this since I became a tech writer; now I want to share some of those thoughts with you.

Congratulations! You hired your first technical writer. At some point you must have realized that you needed one, lest your product becomes a user nightmare. Or perhaps you thought that hiring a writer would free your developers from writing documentation and feel more “agile”. Whatever your motivation, you had the courage to hire a documentarian, and for that we applaud you. Now, how can you make sure your tech writer will thrive?

I’ve recently become a docs maintainer for OpenTelemetry, a pretty big open source project. As I often receive questions on how to start contributing to open source docs, this seemed the right time to write about it. Let me tell you how I started and progressed, and what you can do to start your open source documentation journey.