Docs like code in basic terms

Summary

Docs like code in very basic terms Most guides to docs like code, even the ones for non-devs, assume you have some developer knowledge: maybe you're already using version control, or you've encountered build pipelines before, or you're working alongside developers. This guide is for the people who read that paragraph and wished it came with a glossary. This is docs like code for people who don't know what git is and have never installed VS Code. This post explains terminology and concepts, to help you get a mental model of what's going on. If you prefer to dive in and pick up concepts as you go, skip straight to the tips in How to learn, and come back to the conceptual info as needed. Learn by doing The tools, processes, and patterns discussed in this post make a lot more sense once you start using them. Don't expect the concepts to really click for you until you've got some hands-on experience. And don't be scared to dive in and try things out. Let me emphasise again how simple I'm trying to keep this If you're someone who is going to read this guide and go "what about SVN" or "Emacs is better than VS Code", this article is not for you. Thanks to Craig Wright and Adeline Amar for asking great questions, and providing review and feedback. What is docs like code? Docs like code, also called docs as code, is the practice of treating documentation development the same way as code development. This includes using the same tooling and processes as your development and DevOps teams. The advantages are: The tooling and processes are familiar to developers, so it makes it easy for developers to contribute to your docs. If you want community contributions, it unlocks the same processes as open source code projects use. It provides a really nice way to collaborate: although they have a learning curve and setup effort, docs like code tools and processes are a great way to support multiple people working on the same project, reviewing each other, and getting work live fast. If ...