I think the main error I see when developers try to create a lot of docs, vs the most common "uniformly underdocument", is to get twisted in a pretzel over what

I think the main error I see when developers try to create a lot of docs, vs the most common "uniformly underdocument", is to get twisted in a pretzel over what point or detail to include when, eventually splattering all of it into one form(whether that be tutorial, API reference, or some other idea) while still not covering everything because when you explain everything you eventually end up crossing over into being a programming tutorial. The more systematic approach which I've really caught onto recently is to assume it has to be atomized a bit to get any breathing room. Make distinct spaces for the narratives, spaces for basic concepts and references, spaces for formal overviews, and spaces for single tasks, features and APIs. Then have them link to each other, using the link as the leverage to let each part of the documents use the necessary vocabulary without overexplaining. While it's possible to overdo that and produce documentation that is a thicket of links, just clarifying that you have a distinct purpose to the space makes the writing process much more systematic - no confusion over what the writing needs to concentrate on.