28 ms·

What do you do when some of these mentees (as you put it) get so used to having every question promptly answered that they stop reading the documentation or put

by boris 4y ago

What do you do when some of these mentees (as you put it) get so used to having every question promptly answered that they stop reading the documentation or putting even a modest amount of effort into figuring out why things don't work as expected? To be clear, I am not being facetious/sarcastic; I have this exact problem at the moment (in an open source project) and could use some tips. Surely you (or others) must have run into this. My best idea so far is to throttle my replies proportional to the offences.

zach_garwood 4y ago
I think a simple "I need you to figure this one out on your own today" or "you and Employee 421 should discuss this, they had a similar problem last week" is probably better than just refusing to reply. Ghosting someone isn't a winning strategy.
thomastjeffery 4y ago
Keep answering the questions, but include a reference to the docs in your answer. Your goal is to introduce them to the usefulness of the tool that is documentation, not to simply unburden yourself of trivial questions. If your documentation is good enough to answer their questions, then sooner or later they will start to use it first, because that's easier than asking a question. The next thing you can do is ask them if they think the documentation can be improved, so that the answer to their question is easier for the next person to find. Usually, it's not the substance of the answer that they were struggling to find, but the context that would have lead them there in the first place. When that happens, it feels like your answer is trivial, but that's because the real value of the interaction was encapsulated into the very act of you answering, not the answer itself. Documentation can be a great way of referencing nouns and verbs. Good documentation will probably answer "what?" and "how?". Great documentation will answer "where?". The trickiest questions end up being "when?" and "why?".
- hinkley 4y ago
  You can get people to self serve by putting stuff in the wiki. It’s a good way to make sure things get into the wiki in the first place. Tired of answering the same question? Did you write the answer somewhere? Can people find it? No? Then you’re part of this equation, buster.
ghufran_syed 4y ago
Try the whole "teach them to fish" vs "give them a fish" approach. So give positive feedback for asking, show them how to find the answer online or in documentation, and then over time, your first response to their question will become "ok, what have you tried so far?" and hold them accountable for following the (informational search) algorithm you showed them previously. Some people have trouble turning your advice into a skill they perform routinely (partly because they don't take notes). So you can help them with that by asking them to make notes on what you are showing them, then getting them to send them to you for review. And if the things really isn't online because it’s proprietary and it’s not explained in the documentation yet, then you get them to write the notes with the view to making that the documentation. So they take up your time on a task that helps them in the company, they pay it back with another task that helps others by reducing the chances that someone else gets stuck in future
- jjice 4y ago
  This is what I try to do, and I believe it works out well. Sometimes I can tell that someone is a bit annoyed that I'm not showing them just how to add CSRF protection to a page, but also why we do it and how it works, but I do believe that showing them how to do it and why is where leaning comes in and trumps raw repetition/memorization.
klibertp 4y ago
Create a template of how a good question should look like. This is becoming more and more popular on Github's issues, not sure since when, but I'm definitely seeing it more often these days. Include sections like "what did you try" and "where did you look and what results came up", among others. Auto-close questions that don't use the template; if it's automatic, you're less likely to become a target of hostility due to this. Set up a process of converting questions into docs (wiki works). If a question's quality is too low for its answer to be put into docs, delete it. If it is good enough, make an effort to answer and make it easy to contribute it to the documentation. Make sure it's easy to find both Q and A afterward. Make sure you have a "troubleshooting" section in the docs. Try to assist people with finding the answers on their own as much as you can, but also make sure it's trivial to tell if someone actually read that section and followed the steps outlined there. If you get a question from someone who obviously didn't care to read that, delete it. Make sure your docs are indexed, searchable, and that you're able to link to specific paragraphs (ideally) or at least headings (but then make sure to actually use headings that make sense). The more precise you are when telling people where they should go, the less likely they are to come back to you to ask again. In general: make sure good questions (and their authors) are rewarded and make sure people who don't want to put in the work to make their questions good are easily distinguished. Warn the latter once or twice, then punish swiftly and decisively if they don't improve. Above all else: don't expect your answers to be valued if you, yourself, don't value the time and effort expended to give them. Just because you know something doesn't mean everyone and their cat is entitled to be coached by you. Make it clear that getting an answer from you is a trade: the one with a question has to put in enough time and effort into asking it for you to find it worthwhile to spend your time and effort to answer. Beware of jerks. Just like you can construct malicious packets that make the receiving server do a lot of work for nothing, it's possible to craft questions that amount to a DoS attack on you. Manage the time spent on answering questions and track it. If servicing a single person takes too much of your time, become suspicious. Taking too much of your time may just be their goal. Finally: recruit helpers. People who often submit good quality questions probably dislike low quality questions as much as you do. Let them help you filter out the noise. My 2 c.
jjice 4y ago
As another user said: > Keep answering the questions, but include a reference to the docs in your answer. If it's something like how to set up a local development tool, I'll post a link to our documentation and tell them it's near the bottom. I also let them know that if they run into any issues, to let me know and we can hop in a call.

by boris 4y ago

zach_garwood 4y ago

I think a simple "I need you to figure this one out on your own today" or "you and Employee 421 should discuss this, they had a similar problem last week" is probably better than just refusing to reply. Ghosting someone isn't a winning strategy.

thomastjeffery 4y ago

Keep answering the questions, but include a reference to the docs in your answer. Your goal is to introduce them to the usefulness of the tool that is documentation, not to simply unburden yourself of trivial questions. If your documentation is good enough to answer their questions, then sooner or later they will start to use it first, because that's easier than asking a question. The next thing you can do is ask them if they think the documentation can be improved, so that the answer to their question is easier for the next person to find. Usually, it's not the substance of the answer that they were struggling to find, but the context that would have lead them there in the first place. When that happens, it feels like your answer is trivial, but that's because the real value of the interaction was encapsulated into the very act of you answering, not the answer itself. Documentation can be a great way of referencing nouns and verbs. Good documentation will probably answer "what?" and "how?". Great documentation will answer "where?". The trickiest questions end up being "when?" and "why?".

hinkley 4y ago
You can get people to self serve by putting stuff in the wiki. It’s a good way to make sure things get into the wiki in the first place. Tired of answering the same question? Did you write the answer somewhere? Can people find it? No? Then you’re part of this equation, buster.

ghufran_syed 4y ago

Try the whole "teach them to fish" vs "give them a fish" approach. So give positive feedback for asking, show them how to find the answer online or in documentation, and then over time, your first response to their question will become "ok, what have you tried so far?" and hold them accountable for following the (informational search) algorithm you showed them previously. Some people have trouble turning your advice into a skill they perform routinely (partly because they don't take notes). So you can help them with that by asking them to make notes on what you are showing them, then getting them to send them to you for review. And if the things really isn't online because it’s proprietary and it’s not explained in the documentation yet, then you get them to write the notes with the view to making that the documentation. So they take up your time on a task that helps them in the company, they pay it back with another task that helps others by reducing the chances that someone else gets stuck in future

jjice 4y ago
This is what I try to do, and I believe it works out well. Sometimes I can tell that someone is a bit annoyed that I'm not showing them just how to add CSRF protection to a page, but also why we do it and how it works, but I do believe that showing them how to do it and why is where leaning comes in and trumps raw repetition/memorization.

klibertp 4y ago

Create a template of how a good question should look like. This is becoming more and more popular on Github's issues, not sure since when, but I'm definitely seeing it more often these days. Include sections like "what did you try" and "where did you look and what results came up", among others. Auto-close questions that don't use the template; if it's automatic, you're less likely to become a target of hostility due to this. Set up a process of converting questions into docs (wiki works). If a question's quality is too low for its answer to be put into docs, delete it. If it is good enough, make an effort to answer and make it easy to contribute it to the documentation. Make sure it's easy to find both Q and A afterward. Make sure you have a "troubleshooting" section in the docs. Try to assist people with finding the answers on their own as much as you can, but also make sure it's trivial to tell if someone actually read that section and followed the steps outlined there. If you get a question from someone who obviously didn't care to read that, delete it. Make sure your docs are indexed, searchable, and that you're able to link to specific paragraphs (ideally) or at least headings (but then make sure to actually use headings that make sense). The more precise you are when telling people where they should go, the less likely they are to come back to you to ask again. In general: make sure good questions (and their authors) are rewarded and make sure people who don't want to put in the work to make their questions good are easily distinguished. Warn the latter once or twice, then punish swiftly and decisively if they don't improve. Above all else: don't expect your answers to be valued if you, yourself, don't value the time and effort expended to give them. Just because you know something doesn't mean everyone and their cat is entitled to be coached by you. Make it clear that getting an answer from you is a trade: the one with a question has to put in enough time and effort into asking it for you to find it worthwhile to spend your time and effort to answer. Beware of jerks. Just like you can construct malicious packets that make the receiving server do a lot of work for nothing, it's possible to craft questions that amount to a DoS attack on you. Manage the time spent on answering questions and track it. If servicing a single person takes too much of your time, become suspicious. Taking too much of your time may just be their goal. Finally: recruit helpers. People who often submit good quality questions probably dislike low quality questions as much as you do. Let them help you filter out the noise. My 2 c.

jjice 4y ago

As another user said: > Keep answering the questions, but include a reference to the docs in your answer. If it's something like how to set up a local development tool, I'll post a link to our documentation and tell them it's near the bottom. I also let them know that if they run into any issues, to let me know and we can hop in a call.