People still see documentation as “just text”. For rsyslog, that changed a bit over a year ago.

Docs now need to work for humans and AI tools: clear structure, stable anchors, semantic hints, and examples that code agents can verify.

This turned into real engineering work, not just writing.

I wrote a short article about what’s behind the overhaul:

The Real Scope Behind the rsyslog Documentation Overhaul

https://rainer.gerhards.net/2025/11/the-real-scope-behind-the-rsyslog-documentation-overhaul.html

#rsyslog #DocumentationEngineering #InformationArchitecture

The Real Scope Behind the rsyslog Documentation Overhaul - Rainer Gerhards

How rsyslog’s documentation is rebuilt for the AI era, using HCI, IR, CS concepts, and structured metadata to make the system clearer for humans and AI.

Rainer Gerhards

"I’ve developed the impression that, as humanists in tech, technical writers are constantly subjected to the pull of two separate forces. One is eminently technological, embodied by the Developer-Maker; the other is communicational, represented by the Writer-Storyteller. I see you muttering “Woz & Jobs” in glee while reading about those profiles, and you wouldn’t be too far off, despite how trite those stereotypes have become over time. For the sake of the discussion, let’s assume that they’ve always been there.

If you represented both forces in a diagram, you’d get something like the following: the Developer strain diverging from the initial trunk towards more engineering-colored shades of writing, and the second strain, the Writer’s, moving towards meaning and connection and away from explaining buttons and menus. As UIs become more self-explanatory, and coding more accessible, writers pursue deeper specialization, and so the tech writer becomes an API writer and then a Docs Engineer, for example.

I think it’s still entirely possible to remain at the center as a full-stack writer, but it’s becoming harder due to the way job titles convey expectations and foster teamwork. It’s easier for tech writers to embed with engineers if they carry the engineer sobriquet, as it’s simpler to work with designers if you attach the UX patch to your business card. It’s all meant to say “I understand and respect your work, let’s collaborate”. And since technical writing is a landing pad, switching between those sides isn’t impossible."

https://passo.uno/what-is-a-documentation-engineer/

#TechnicalWriting #SoftwareDocumentation #DocumentationEngineering #Docs #SoftwareDevelopment #Programming

Why I became a Documentation Engineer (and what that even means)

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.

passo.uno