What is Docs-as-Code?
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjZt4Vbe673NGwziLE5uchEtV9gvduzMdrr1-CqEgLF9fbBtYtg5xkhr5SvkjPmFWLFX316XH-NeS0zyq3eZSL0qUd7BPZYCwmga7n7x-hz0WLR6CgTOFieUYhvUTXxNigZS8jLLCxHN4IRwOwkqOHhuv3VrBrBJFUmQEhpHR4woWdPQfwoo997novCfK0/s320/docsadcode_rep3_DALL%C2%B7E%202024-11-09%2013.18.04%20-%20An%20abstract%20and%20modern%20visual%20representation%20of%20the%20Docs-as-Code%20workflow,%20showing%20elements%20of%20a%20documentation%20process%20without%20any%20text%20(except%20simula.webp)
The Docs-as-Code (DaC) approach to writing documentation has been gaining popularity in the last few years. Although it's a relatively new term, people have been using DaC-style workflows for almost as long as computers have existed. They just didn't call it "Docs-as-Code." The fact that lots of people have now heard the term is a testament to how many more people (and companies) are using the DaC workflow. To be clear, parts of this post will be my opinions about DaC. I've used some form of DaC for my entire career in the software industry, most recently as a Technical Writer. While it's true that some people raise objections to the DaC workflow, I find it telling that DaC is used both by startups and the largest software companies in the world. For example, Meta, LangChain.com, Python’s official documentation, Django docs, and Apache.org all use DaC. As with any approach, DaC has its own set of advantages and disadvantages. In this post, I’ll define the DaC ...