Stay current with the latest in tech comm
Keep current with the latest trends in technical communication by subscribing to the I'd Rather Be Writing newsletter. 5,000+ subscribers

Stitcher radio

Search results

Upcoming event:
I'm giving an API documentation workshop in San Francisco, California, on November 19, 2019. Check it out on EventBrite and register today to receive a $100 early bird discount.

Recording of Docs-as-code tools and workflows presentation

by Tom Johnson on Mar 9, 2018 • 0 Comments
categories: api-doc

I recently gave presentation to the Rocky Mountain STC on "Docs-as-code workflows and tools" on March 9, 2018. The docs-as-code approach is most common in the developer doc space. In this presentation, I explore the upsides and downsides of treating documentation as software code, and what details are involved in adopting engineering tools, workflows, collaborative processes, and other practices. You can view the recording, listen the the audio, and browse the slides here.

Video recording


You can view my slides here:


Event description

Here’s the event description:

Docs-as-code workflows and tools

If you plan to involve developers in writing and editing documentation, you might have more success by adopting the same tools developers use for software coding. This approach is often called “docs-as-code.”

To treat docs like code generally means doing some of the following:

  • Working in plain text files (rather than binary file formats like FrameMaker or Word).

  • Using an open-source static site generator like Sphinx, Jekyll, or Hugo to build the files locally through the command line (rather than using a commercial program such as FrameMaker or Microsoft Word).

  • Working with files through an IDE such as Atom, Sublime, or another text editor (rather than relying on commercial tools with proprietary, closed systems that function like black boxes).

  • Storing docs in a version control repository (usually a Git repo) similar to how programming code is stored (rather than keeping docs in another space like SharePoint or a shared drive); also if appropriate, potentially storing the docs in the same repository as the code itself.

  • Collaborating with other writers using version control such as Git and GitHub to branch, merge, push, and pull updates (rather than collaborating through large content management systems or SharePoint-like check-in/check-out sites).

  • Automating the site build process with continuous delivery to build the web output from the server when you update a particular branch (rather than manually publishing and transferring files from one place to another).

  • Running validation checks using custom scripts to check for broken links, improper terms/styles, and formatting errors (rather than spot checking the content manually).

In short, treating docs like code means to use the same systems, processes, and workflows with docs as you do with programming code. In this presentation, we’ll dive into each of these aspects of docs-as-code in depth and explore the advantages and disadvantages of the approach.

Event details

The event was hosted through the Rocky Mountain STC group. You can view the event details here: Docs-as-code workflows and tools.


Metropolitan State University of Denver: Room CN 113
1198 11th Street
Denver, CO 80204


Fri, March 9, 2018
6:00 PM – 8:30 PM MST

follow us in feedly