FWIW, documentation isn’t very good anywhere. I’ve been at many companies, and it’s always been varying levels of mediocre to bad, even with a dedicated team of

FWIW, documentation isn’t very good anywhere. I’ve been at many companies, and it’s always been varying levels of mediocre to bad, even with a dedicated team of documentation writers. My recommendations are: - DO Try to rally the whole team to contribute. Attempting to write useful documentation yourself for more than one or two other people’s code is a Sisyphean task. - DO Make documentation (and testing and debugging) part of the job and the culture of programming. The best documentation is written by the same person that wrote the software. In my experience, it’s surprising how often I bump into programmers who believe that testing and docs are not part of their job. - DONT try to document everything. There’s too much. There are too many people writing code faster than you can document (especially if they’re not documenting along the way). It’s also unnecessary, most code is only seen by the people that wrote it, most code doesn’t need separate written documentation aside from code comments. Focus on the documentation that is most needed by the widest audience. - DO Focus on a small number of specific workflows, like onboarding, and gather continuous feedback on your documentation from the people who use it. - DO Establish a plan to version your docs and more importantly to delete old and obsolete documentation. Having a massive sea of outdated docs has been half the problem in my experience, old docs can be confusing and misleading, and having to wade through them to find the right stuff wastes time and energy.