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.

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.

Some months ago I wrote a post about open source docs contributions. My dear colleague Scott Abel (The Content Wrangler) found that to be a good topic for a webinar, so today I hosted Contributing to Open Source Documentation Projects, where I expanded my thoughts on the topic and provided some practical guidance. You can also download the slides here. Enjoy!

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.

Last week I had the pleasure of conversing with Niklas Begley from Doctave. It was a follow-up to The Pros and Cons of Markdown, focused on why Markdown and other lightweight markup languages could benefit from some structure, in the DITA sense, but without going the XML way. Hint: There could be a bit of JSON schemas involved.

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?