> However, some people come to me with questions already answered by the documentation. They aren't interested learning anything,
Not entirely a counter, but i think it's worth remembering that because documentation is difficult - a lot of people have been trained to ignore documentation by way of documentation not being the answer in far too many cases.
I'm sure there are many people whose behavior is driven by the reasons you give, though.
The problem is that often people come to you and just want a solution to their particular problem. Then you explain but forget or leave out some details because you assume they know those. If you're too verbose, they might just have read the documentation.
In fact the best thing to do is to point them to the correct paragraph in the correct document.
I think documentation feels like a bit of a sink, as written documentation starts degrading (in terms of being up-to-date) as soon as it gets published, and it gets extremely frustrating going through docs and not feeling like you can "trust" what you're reading
It depends on whether you have better people skills or better reading comprehension. I use whatever source gets me the answer fastest as I am skilled in both. That's not true for everyone, but being able to use a decision tree where you have both options is a big part of being a 10x programmer IMHO.
Is your PM/BA/Coworker so overwhelmed they can't think straight (Mind your P's & Q's)? -> Go look at the docs.
Can you politely insert yourself into a conversation with a coworker given their bandwidth and their ability to understand functional and technical requirements and quickly explain what is required? -> Schedule a short meeting.
Not entirely a counter, but i think it's worth remembering that because documentation is difficult - a lot of people have been trained to ignore documentation by way of documentation not being the answer in far too many cases.
I'm sure there are many people whose behavior is driven by the reasons you give, though.