Search results

Recording of Docs-as-code tools and workflows presentation

by Tom Johnson on Mar 9, 2018
categories: api-doc • api-doc-site-updates

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 audio, and browse the slides here.

Video recording

Slides

You can view my slides here:

Audio

Listen 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.

Location:

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

Time:

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

About Tom Johnson

Tom Johnson

I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.

If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.

© 2024 Tom Johnson