We should use a term that is more clinical in technical writing. The "empathy" we're aiming for is fully understanding the user experience. That is a correct use of the word, but the popular usage is closer to "sympathy," and often people are using it to indicate they care about treating people well in a broader moral sense. (E.g. "do unto others" is morally empathetic.)
The difference is that being empathetic morally is an end in itself, whereas being empathetic technically is a means to an end. Dark UI patterns, for example, are very empathetic in the technical sense in that they use understanding of the user to manipulate them.
I can't imagine anyone else does anything but this aside from initial foray into a API
Your API has a purpose. It does things. I know what that is, that's why I came here to use your API. I can verbalize what I want your API to do for me, and that is what I will search for. I will not look at your whole documentation, I do not care about your general concepts. All your ideas about architecture and design stand between me and my goal. I want you to apply the principle of least astonishment. If there's something non-obvious that might cause issues, mention it in all the places where it applies. Yes, this goes against your urge to not repeat yourself. Do not give in to these urges.
Sometimes people design APIs with great flexibility in mind, requiring you to assemble a great many parts in the right shape to achieve your goal. This is almost certainly not what the user wants. If you intend to design such an API, use the "layered" approach. At the top, there should be the most common functionality, as obvious as possible, with as little configuration as is reasonable. This is the layer that almost everyone will need - and not more. This layer is implemented using the more flexible layer below.
I've been using SQLAlchemy for about 3 years now and I have used it to make my life so easy that I feel bad for other people who struggle with SQL.
Does this mean I am not familiar with it or that I know exactly what to look for?
Food for thought for you, perhaps.
The takeaway, though, is consistent with what I've seen... people like code examples! Most people will scan until they see one, and start there. The heavy focus on API Reference in this study makes me think either the tasks were too specific, or the tutorials weren't comprehensive enough. For a good documentation site, most use cases should be covered by topical guides. Going to the reference guides to learn an API is like reading a dictionary to learn English. There's not a lot of context.
That doesn't necessarily have to be the case. Back when I was at an IoT startup I structured the reference docs based on the order that a developer would typically use in order to get common tasks done. E.g. call this method to get the device's identifier, and then here's a list of methods that let you do stuff with the device. Chris Bush presented a similar idea  at this year's Write The Docs conference. His main argument is that the organization of reference docs is usually implementer-oriented. E.g. alphabetical. In many cases it may make more sense to have a user-oriented organization, one way or another.
This is absolutely the biggest (and easiest) mistake people make when designing APIs. Force developers to use their own APIs as end-users - quality will improve significantly.
So you get developers hating it and users (especially admins and distro packagers) loving it (well, packagers who have to build a lot of stuff sometimes dislike the performance).
Packagers have some trouble getting fixes to these build systems to stick. Cue Gentoo autotools.eclass with automatic application of generic set of fixes for all the brokenness of the ages.
What's especially fun is when the "code examples" for a http API use a client library which hides the actual http API, so they aren't examples of using the API at all...
Exactly! Examples are usually the most useful thing in the documentation.
Based on my experience, people go first to the examples and then read the description.
I guess that's also why stackoverflow is working so well as it is basically a large library of examples.
It would massively improve discoverability.
That and give a single large actual example of interacting with the API.
That said I’ve always preferred reading code using a library over reading docs for the same library.