But they sort-of do, no? The left hand side bar has the top-level (bold) headers "Home", "Start Here", "Applying Diátaxis", "Understanding Diátaxis" and "Colophon". The middle ones could well be labeled "Tutorial", "Explanation" and "Reference", but that would be very confusing for the reader!

Some places still have very good tech teams, but it still requires working between the teams. (EX from a company I worked with: https://forums.madcapsoftware.com/viewtopic.php?t=30365)

The writers can't do their work without input from the technical side and the time for that is often not avaliable.

I know I've been punished for taking time to push ideas to tech writers. Not only does it slow me down in other places, it often gets swept away as unnecessary changes because upstream Sr techs disagree.

For example, when I modify ssl configs, I alway reference the files with soft-links. This makes it so you don't need to modify the config files and simplifies keeping old and new certs so you can flip back during the overlap period you should be providing to test. I try to avoid editing production files by hand whenever possible because in my experience it introduces the possibility to create errors.

I rewrote some docs extending alot of areas with example commands showing how to test things, with explanations that fleshed out the previous quick and dirty documentation. I also modified the method from copy and replace certs, edit files, restart service; to copy files, replace or create soft-link, restart service.

Upstream approvers trashed the whole thing because the thought it was unnecessary and disagreed with me about manually editing config files.

> By natural selection, anything that survived the good old days is either obvious or well documented

Or so much better than the competition that people use it in spite of poor documentation. Many things like that also grow a cottage industry of people making documentation and teaching (see React or Rails).

Yes, the upside of the contemporary on-line software distribution is clear. No question about this. "The good old days" :-) reference was only about the comprehensive and ordered documentation that often used to come with the physically shipped software medium.

Often referred to, as “recipes.” —Defining the goal, and a specific set of steps, to achieve that singular outcome.

How to calculate the airspeed velocity of an unladen swallow, etc.