Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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:
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.
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.)
Sep 9, 2011 at 12:33
Don't say no. But don't answer immediately either.
Make it clear that:
and ask your co-workers to:
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.
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:
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.