Probably the second most important asset to have when using a software library (the first being the library itself, of course) is documentation for how to use that library. In Ye Olde Days, the stature of a computing department would be indicated by how big their "wall of manuals" was.
I was going to insert a photo of such a wall here, but "picture of thing that existed before the Internet" is hard to find on the Internet. Here's a photo of a cute kitten instead, because finding those on the internet is easy (Figure 1).
Unfortunately, another thing that's easy to find on the Internet is misinformation, and documentation for software libraries is no exception. For new projects, the project's web site likely has the correct documentation for whatever version you have (assuming it has any documentation at all), or at least close enough. After a project has been around for a while, you have to dig a bit to find the documentation that corresponds to your version of the code—a search engine might give you documentation for the wrong version, or maybe someone's forked variant, or even another project that only resembles what you have. I won't even get started on opinions found in random forums or the garbage, er, "synthetically generated but not always correct information," AI can spit out that sounds official.
It gets worse
Now consider the core C library and OS interface, which have been around for decades. Do you know where the official documentation for those are? Hint: you're probably wrong. For the GNU C library, which is one of the core libraries of Fedora and Red Hat Enterprise Linux (RHEL), the authoritative documentation is the GNU C Library Manual. It's in the glibc-doc package on Fedora, and can be read with the info reader program.
Don't know what all those are? You're not alone. If you still remember how to get a command line prompt, type info libc. You can find a version online if you know where to look (for example, here if you're using an unmodified release of glibc), but keep in mind that version X.Y of glibc in RHEL is not the same as version X.Y of glibc in Fedora.
Also, because the license for the glibc manual is the GFDL instead of the GPL, some distributions (for example, Debian) don't include it at all, as there are parts of the GNU C Library Manual that no one is allowed to change. (Mostly copyright notices and attributions as per the GFDL, but including an entire appendix advocating for Free documentation, which can neither be removed nor altered.) This can sometimes discourage developers from updating the manual, if nobody is going to read it.
What you probably thought was the documentation is "the man pages" (specifically, the Linux Man Pages Project) and while they do cover nearly all of the C API, they are not authoritative for the GNU C library (although recently specific versions have been adopted as "authoritative but secondary to the manual"). They are typically correct, but they're not part of glibc, so glibc can't guarantee you get the right versions. Sadly, there are things provided by the GNU C library that are only documented in the man pages! Again, though, the GFDL means that work can't be shared between the man pages and the glibc manual, because many of the man pages are GPL.
Frustrated yet? Let's also add the various standards that the C library must conform to; the most important is POSIX, which has its own documentation.
But what about the kernel API? Surely the man pages are authoritative for the kernel, right? Well, if you look for the kernel's documentation, you mostly get documentation for the kernel internals. The system calls' documentation is mostly left to the man pages on an ad hoc basis. The man pages project has had at most two maintainers in its history, who sometimes have to chase developers down to get documentation for their changes.
What's so hard about writing documentation?
If you're asking yourself "what's so hard about writing documentation?", there is a secondary problem. The man pages are written in a very old language called roff. Never heard of it? Most people haven't. Ironically, roff is itself not well documented, nor are its modern extensions nroff and troff. GNU has its own roff interpreter called groff, which is documented in Texinfo.
Texinfo is itself an old language, created by the GNU project for its documentation. The advantage of Texinfo is that it can produce many modern formats, like PDF, HTML, or plain text. The disadvantage of Texinfo is that it's not as popular outside the GNU project, so few know how to write docs with it. Neither of these formats are as popular as, say, the modern Markown format used by wikis.
What can you do about it?
If all this bothers you, well, I have some suggestions:
All the projects mentioned above welcome new volunteers, especially if you like writing documentation and learning new (er, old) languages.
You could let the various docs maintainers know how much they're appreciated.
Getting your company to allocate time or resources to help improve documentation would be fantastic.
Or you could look at the cute kitten some more.
