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.

As a Documentation Engineer, I’m expected to have a decent understanding of code in several of the programming languages we use at work, be able to use developer tools and developer environments, write code samples, automate the boring bits of my work, and support other developers in their writing quests as a devling. The other day, for example, I added a new feature to the docs site with the help of AI. This required understanding the stack where I added the feature. I wasn’t just praying to the AI gods.

Does this mean that I’ve stopped writing documentation? Not at all! I still document procedures, and I even support designers when they need UI text. I take care of rallying teams to fill out the changelog and I also look after tools that’d help foster contributions, such as templates and linters for our style guide, which I developed. The emphasis, though, is on being technically proficient enough so as not to require constant hand holding by engineers while at the same time asking them the right questions.

Leave a Comment