Possible Duplicate:
When do you not give help to less experienced programmers?

Currently, I am finding a lot of my day is taken up by people asking domain knowledge/system questions. This impacts personal productivity.

Should developers learn to say "no" more to ensure they get asked less questions and be more productive, or should the developers help each other out? Stuff does get documented, but it is often easier to ask a "quick question".

How do you handle this sort of scenario?

  • 47
    How can you expect any other answer but "NO!" to this question?
    – user1249
    Commented Sep 9, 2011 at 10:54
  • 32
    "This impacts personal productivity"? What? How do you know that your personal job is not to answer questions? Talk to your boss. You may be more valuable answering questions than doing whatever other thing you think is important. I think asking random strangers what value you create in your organization is less than optimal. You should consider asking your boss first, and including that insight into the question.
    – S.Lott
    Commented Sep 9, 2011 at 11:07
  • 4
    Are you a consultant ? If it is the case, prepare to be consulted !
    – Guillaume
    Commented Sep 9, 2011 at 11:51
  • 6
    Your problem is being interupted, not people asking questions. Are you sure you're not doing he same thing and this is just the way your group is operating?
    – JeffO
    Commented Sep 9, 2011 at 12:09
  • 1
    If something is documented, send them the document. If it's not documented, ask them to e-mail you the request and let them know you'll reply later. Then you can stay in the zone now and work through the question/answer stuff in batches later. (E.g. set aside 1 hour each morning to do Q&A.) Commented Sep 9, 2011 at 14:07

15 Answers 15


I've been in this situation before.

First of all, don't say no. Never refuse to provide people with answers to their questions. Instead try to guide them into an "appropriate" way of getting those answers.

This is what worked for me:

  1. If you're not the right person for the question, redirect them instead of answering yourself. This prevents you becoming the "go-to" guy on all questions just because you always answer them.
  2. All non-urgent questions must be asked via mail. Refuse to answer people at your desk and tell them to send you an email. When questioned on this policy, explain that this helps you organize your day and improve the quality of the answers to questions.
  3. Ensure that documents or wiki entries exist for questions that are asked more than once. When someone asks you a question whose answer is in a document, mail them the document while they're standing right there at your desk. This dovetails nicely with the questions-by-mail policy because you can just forward a previous answer.
  • 17
    +1, it is all about managing the interruptions. Simply saying "no" harms your image and also sends people off to do things without adequate information. Perhaps even more insidiously, it will discourage people from interrupting you with a question before something really bad happens.
    – Angelo
    Commented Sep 9, 2011 at 12:04
  • 5
    don't say no Or, at least, don't say no directly. :) Commented Sep 9, 2011 at 12:34
  • 2
    +1 for point 2 especially. This allows you to time-box your question-answering activities. Just explain this really politely and people will get it. Commented Sep 9, 2011 at 13:09
  • 4
    +1 On point 3, "mail them the document" would be even better as "mail them the link to the document/wiki entry" - that way, they are less likely to wind up referring to out-of-date documents in their e-mail.
    – user4234
    Commented Sep 9, 2011 at 15:33
  • 1
    I like #2 a lot!
    – Chris
    Commented Sep 9, 2011 at 17:13

What about producing a Wiki, so you can share that knowledge so when people come and ask you can say, "have you looked at the wiki?" and then that grows into a excellent documentation resource, as people should add their experience to it.

Where I work we do this and I found over time I only got asked questions that were not so obvious as they were answered in the wiki.

  • 1
    -1 Stuff does get documented, but it is often easier to ask a "quick question" A wiki is no silver bullet. If the culture is correct for it, i.e. the wiki is actually maintained, then it certainly can be useful. Otherwise, it can actually be worse. (Incorrect documentation is worse than no documentation.) Commented Sep 9, 2011 at 12:33
  • @George Marian: I agree with "Incorrect documentation is worse than no documentation" however with a wiki the quality of the documentation should be maintained by the users. I do agree with you as well that a wiki is not a silver bullet, but from my experience it prevents people from asking you the same question over and over again.
    – user18041
    Commented Sep 9, 2011 at 12:39
  • 1
    Only if it is maintained. Take it from someone that had to make use of a wiki which was woefully out of date. You follow directions on how to setup your dev environment, only to find out that several steps are missing, several steps are just plain wrong and several steps don't actually apply to a dev environment. Commented Sep 9, 2011 at 12:43
  • 2
    @George. If you find that the wiki is wrong, then you should update it with what you discovered. That's the whole point of using a wiki versus handing somebody a binder of SOPs. Commented Sep 9, 2011 at 14:07
  • 4
    @George - I had this situation recently, where the company Wiki was missing information, so I asked, and then updated the Wiki myself. If 30 people spend 5 minutes a day updating an outdated wiki, it'll be turned around in no time, and those five minutes updating the wiki could save time because he can in future just redirect people to the wiki instead of repeating himself. The added benefit here is that once the people with questions start getting the "look at the wiki" response over and over, they'll start going there first. It's the old "Give a man a fish" vs "Teach a man to fish". Commented Sep 9, 2011 at 16:10

Don't say no. But don't answer immediately either.

Make it clear that:

  • you like to help out,
  • you have your own work to do,
  • you need to be able to do so without being interupted all the time

and ask your co-workers to:

  • batch questions so you work through a number of them in one sitting,
  • work on something else if they have a question that means they can't continue with what they are doing right now,
  • ask specific questions and show what they have done so far and where they are getting stuck,
  • ask questions in e-mails so you can think about the answer before you sit down with them.

It's something I have done with new colleagues that I was assigned to coach. It works quite well. They save their questions, often answering them themselves as they get further into the issue. And of course, they do know that when something urgent comes up that they get stuck on, they can interupt me.

  • Best answer, +1! Commented Sep 9, 2011 at 16:42

Talk to your manager and explain the situation.

It is his job to ensure you are productive and can do your job effectively.

One possible solution could be a "question hour" - where you can only be approached for questions within that one hour in the day and would be off-limits otherwise.

As for widespread knowledge sharing - there are several ways to do this. Run weekly sessions about the domain, the code base, design decisions etc, to ensure everyone is on the same page. Start a wiki to document this knowledge (a glossary is a good place to start) and every time someone asks a question add it to the wiki. Start pointing people at the wiki and encourage them to add to it and update it.

Of course, any solution that you come by should be suitable to yourself, your manager and the company.


We had a similar situation in our office that is shared between developers, testers, and the relatively small help desk. When the help desk got a question they couldn't answer, they would ask a developer or tester for assistance. Over time, the help desk people asked fewer questions overall but they began asking the same person all the time because that person was either the most helpful or maybe the most pleasant to deal with.

That worked well for everyone but that one helpful developer that was getting all the questions (some of which could take a while to deal with). He was being very helpful, but not getting much development done.

We ended up instituting a developer of the day that became the go-to person for all help desk questions. If question was more appropriate for a different developer he would refer the question to them, but the help desk had to start with the developer of the day.

We rotated the responsibility between 5 developers. Each developer only had one day per week of major interruption and the help desk couldn't just wait until it was their favorite's turn because that could be several days off.

You should take it as a compliment that everyone respects your knowledge and is comfortable coming to you for help. That really is huge. Now you need to help your teammates grow in their expertise and ability to assist coworkers.


Answering seemingly stupid questions might well be a part of your job.

Suppose you are twice as good at programming as anyone else on the team. You get to the solution faster than anyone else, create fewer bugs than anyone else, create better documentation than anyone else. If that is the full gamut of your skills, you'll still be a lowly programmer in your employer's eyes. A very good programmer, but just a programmer.

Your value to your employer becomes a lot greater if you also have the ability to migrate those phenomenal skills to other members of the team. In your employer's eyes, having you spend all or most of your time helping and mentoring others might well be better for the company as a whole than having you spend your time programming.


It really depends on who's asking, and why they're going to you specifically.

If they're all junior devs, new hires or similar, and you are a senior dev or appear to be (for whatever reason) the person who knows the most about the system, they may go to you to avoid making a mistake that might make MORE work for you in the longer term, fixing their mistakes.

As to how to fix it some options inclue:

  • start a wiki where you post answers to questions you receive more then a certain number of times.
  • spend a few days making the documentation better for answering quick questions
  • set up a specific email folder and filter so that they can send you questions at any time but they get filtered and you answer them for a set (small) time each day/week.
  • pass the question answering responsibility onto someone else as knowledgeable as you (so they don't just pass it straight back)
  • Spend a strictly fixed (maybe an hour) time answering any questions, and make it well known that you won't answer with anything more then a yes or no outside that time

I understand feeling the need to get up and walk around the office talking to people every once in a while. I do it myself when I need to clear my head and approach a problem from a different mindset. Others might too.

What is terribly rude though is when people show up and just start asking questions or engaging in discussion with you without asking for your permission first. You will have these in every office. Personally when I approach somebodies cube I say hi, and the first thing I ask is if right now is a good time. If they say no I smile and say I will come by later.

As simple and obvious as it seems some people don't do this and from what I have learned no amount of directing to documentation, subtle hints of aggravation, or saying no will get them to stop doing this. It really is a fact of life that you just have to learn to deal with for the most part.


assuming these questions are work related then I think the only thing you need to do is book your time appropriately. If you spend an hour helping someone on another project get a booking number out of them for that time, if they provide you with one you should have evidence that you are productive, if they can't provide one then you have justification to not spend your time helping them or to escalate it to management.


Than explaining each and everything, just guide them to the place where they can find the answer. As times goes, they will start looking for the answers on their own


I hate to say it, but: Is this good for the company? If what you're working on is more important than what they're asking (to the company's bottom line), then say "I'll help you when I'm finished with this." If, honestly, their problem is more pressing to the company's success, say "I'll help you in two minutes." And finish your train of programming thought.


I would by all means answer them, but if it becomes too much there are some things you can do to improve the process.

  • Try to teach them to answer the questions themselves: show them where relevant documentation can be found, how to find out who knows the most about the stuff etc.

  • Make clear to them that it is good style to first do a little research themselves, and if that doesn't help to collect some questions such that they don't come to you every few minutes.

  • Define some "don't disturb" hours.


I generally see question answering as increasing the overall productivity of the enterprise - especially if they're domain / business insight type questions that can't just be googled / RTFM'd.

If in a given hour two people are stopped and I'm working, that's less productive than me spending 10 mins answering each person's questions. The first asker can then get working for 50 mins and the other two of us then working for 40 mins.

I see it as removing roadblocks or bottlenecks. If you're more senior you may have access to context that the others don't. Especially if what they're actually doing is coming to you not with a question, but looking for a decision to be made. You may have the context to point them down the right path (e.g. the customer doesn't need it to have that bell & whistle, move on versus that's a great enhancement, the customer will love that)

That said, several of the techniques listed elsewhere for getting the regularly needed knowledge documented are also vital to save everyone time in the long run.


I find that a little (stress on the little) well-placed rudeness or condescension goes a long way towards solving these issues.

If the question is a good one and the person has made an effort already, make an effort yourself to help them. This is part of your job. Use the suggestions in other answers to regulate the flow of questions.

On the other hand, if they have interrupted you instead of reading the docs or are saddled with an obviously googlable question (which is what I think you are referring to as "a quick question"), do say something along the lines of "why don't you just google this?" or "can't you read the docs yourself?". You might consider adding some profanity if it's an oral discussion and your work environment allows for it. In any case, convey that you don't think that this was an warranted interruption.

It's not the nice-guy answer, but you need to get things done. If people are interrupting you constantly instead of reading the docs, they are the ones being rude in the first place and abusing your niceness. Most people get the hint very quickly.


How sure are you of most of your day being eaten away by this? I'd suggest tracking for a week to see what is really happening. Perhaps you get a few questions a day but seems like more as those become your highlight/lowlight of the day. The key being to get some hard data first just to confirm what you suspect.

Second, after you have the data, take a look to consider how good or bad was it to answer those questions. Maybe things worked out really well because you answered those questions and so your company did better than it otherwise would. Alternatively, you may now really see how much of your time is being sapped up by these questions. This is where I'd try to formulate various strategies to improve but also to state what general operating procedures are there here. For example, in some places I've worked it wouldn't be unusual to see developers ask, "What's the ticket # for this request?" and if there isn't one, kindly ask the person to make a ticket and then you'll be happy to help as the request is properly tracked in this case. While this can seem annoying to be sticking to policy the idea here is that if there is a ticket then the work is tracked while if there isn't, who knows how many questions were asked here.

Third, confirm with your manager and co-workers how much time should be spent doing this kind of stuff. If you are more senior in the team or been at a place longer then you may be expected to do knowledge transfer and help get others up to speed. Should you be protected more than you are now? Should you answer other questions more and that really is most of your job now? I don't know but this should be a discussion had at some point.

Not the answer you're looking for? Browse other questions tagged or ask your own question.