Generally when I engage with people I'm looking for opportunities to teach them in a way that they won't need me anymore. More simply, I treat "help" like issue triage.
a. If the help is production impacting or blocking an issue that is due soon then they'll get more direct feedback but I'll continue on with (b) as well.
b. Send the person in the direction of resources that aid self-learning.
Habitual help seekers
Some people are habitual in their search for help. I don't run into this as much as I used to, but when I figure out that someone is placing me much higher up on the help tier than my time allows me to be I will generally start continually referring them to (b). If things are bad enough then I'll generally talk to their mentor about refining their learning process. I usually find this where folks haven't "learned how to learn" yet; although software engineers do have a good reputation for learning things outside their domains, there's no shortage of folks who just know how to string code together.
If the question should be in a document, then I respond by opening the documentation and checking to be sure the documentation is right, and then fixing it as needed. That done I tell them to read the documentation and let me know if anything is hard to understand so I can fix it.
When writing it is very easy to skip steps that are obvious. So when "asks too many questions about the obvious" can figure it out from the documentation I know the documentation is finally good enough for everybody - including the person who doesn't ask enough questions.
That's an interesting approach. Generally speaking, my organization doesn't maintain large document repositories because they go stale quickly and our products are too vast to document in such a way.
For some context on my reply:
- We maintain one design document per project. This document references everything from the application specifications to the automation that puts it in production.
- Most documentation is written in line with code. Finding documentation is about as complicated as finding the right repository.
This is also why peer review (in our org) isn't limited by level. Ideally we'd get feedback across the experience spectrum to make sure not only code but comments make sense to everyone.
That is why step one is review the documentation. If documentation isn't reviewed regularly utility is useless. By using questions as opportunity to review it I can keep it useful.
This comment resonates with me as I'm currently the one habitually asking for help! Coming to the realization and accepting the issue has been tough but I'm actively working on it these days.
a. If the help is production impacting or blocking an issue that is due soon then they'll get more direct feedback but I'll continue on with (b) as well.
b. Send the person in the direction of resources that aid self-learning.
Habitual help seekers
Some people are habitual in their search for help. I don't run into this as much as I used to, but when I figure out that someone is placing me much higher up on the help tier than my time allows me to be I will generally start continually referring them to (b). If things are bad enough then I'll generally talk to their mentor about refining their learning process. I usually find this where folks haven't "learned how to learn" yet; although software engineers do have a good reputation for learning things outside their domains, there's no shortage of folks who just know how to string code together.