The more questions I ask, the more it seems that people have slightly different ideas about the definition of the term "Docs as code."
Here's one definition, based on some of the best-known resources about docs as code.
* The docs are written in plain text.
* Source files are stored near the application code, usually in the same repo.
* The tools for editing and reviewing documentation are whatever the developers _in the same organization_ use to write code.
* Automation transforms the source files into a website and sometimes other forms of output.
* The reason for adopting all the measures above is to enable developers to write documentation.
The last bullet is the most frequently omitted from definitions of docs as code, but I would say that it's the most important.
Coming up: More about Docs as Code and other toolchains.
"The last bullet is the most frequently omitted from definitions of docs as code, but I would say that it's the most important." — I agree that this is often very important, but docs as code has strong benefits even where the process does not involve software developers *at all*.
That's because a docs as code toolchain can make documentation *much* easier to track, review, maintain and deploy than is often the case with more traditional approaches. This means that technical writers can publish specific updates and fixes to documentation faster, with better traceability.
That's all extremely beneficial to any organisation, not just those that revolve around software developers.