If it's technical docs for developers, you'll get more bang for your buck by making executable documentation first - tests, deployment automation, build automat

If it's technical docs for developers, you'll get more bang for your buck by making executable documentation first - tests, deployment automation, build automation. Make it so that to do 1 logical action then there's only 1 step needed. How do i build this? Run the build command. How do i test this? Run the test command. How do i run only the unit tests? Run the unit test command. How do i start this locally? Run the start-local command. How do these components interact? Run the contract-test command. ... That fixes "reference" type docs better than any reference doc but there's still a place for technical guides around a code base but short screen recordings voiced over by an experienced dev on the project navigating their IDE will beat any written guide on any metric (time to write, usefulness etc.) If it's customer facing docs, treat them as code and host them inside the application in some way. There's few things worse than reading the wrong version of a doc.