The old problem with software documentation is that it’s written by documentation writers, and not by the engineers who write the code, and are typically inarticulate, impatient and secretive when interviewed by the writers. In my career, writing code for internal use (by those same engineers, by the way) we wrote our own documentation, and it was better than any published docs I had ever seen, including the docs for use by the company customers. Our motivation was simple: we didn’t want to explain ourselves over and over again. RTFM was our usual answer.
Problem with engineer documentation is that it’s not functional or practical for users. I’m guilty of it myself. I have Visio diagrams, Excel spreadsheets, Word documents with procedures all over my local and network disks. My job is to consolidate it for presentation to our non-technical executives. They love that stuff.
My group did the same. Users rarely had to call to ask how to make something work... it was all covered. We usually only heard something if a bug in the code popped up.
I have that on my coffee mug.