A note on terminology

Much like the terms developers, engineers, and programmers, practitioners in this field also refer to themselves in ways that are mostly the same but mean different things to those who use them.

The two main terms you have likely heard used interchangeably are “technical writing(er)” and “documentation”, plus maybe some other terms appended. These terms mean more or less the same thing, at least more so than with programming-related role titles, but many of us still take issue with them and prefer other, more inclusive terms.

For example, as I will cover in Chapter 8, Collaborative Workflows with Automated Documentation Processes, a lot of technical explanation is far more than words these days, and our typical titles reflect a rather out-of-date viewpoint. I also believe that a documentation portal may not always be the best place to explain everything. I experimented with “technical communicator” (which I still have on my LinkedIn profile at the time of authoring this book). I’ve also heard “documentation engineer”, which I quite like as it reflects that many of us at smaller companies also build a lot of tooling for documentation. However, what a lot of technical writing communities have settled on to include everyone is “documentarian”. It’s not perfect, but it reflects that not everyone who contributes to or cares about good documentation has a full-time role dedicated to that task. I assume, much like many of the readers of this book. So, that is the term I will use to refer to you and us throughout the book. Concerning our work, I will use the most relevant term to suit the use case and output. For example, documentation, blog posts, videos, and so on.

I will also use the terms “project” and “product” somewhat interchangeably to refer to what you are documenting. In my mind, a “product” is something commercial, whereas a “project” might not be. However, a few caveats and small differences aside that I will address when I get to them; they are essentially the same.