127

I'm a senior developer at my workplace. A coworker in my sister team… isn't. They're also a textbook help vampire: they face an issue, they don't understand it, they miss the error message, they misdiagnose the issue, they ask people for help (often privately, via video-call), they misunderstand the advice, and they move on to the next person, until finally they stumble upon a misfix that happens to dribble around the original issue.

This approach to problem solving gives me the proverbial red mist — the computer program is telling you right there in plain English what it is that you need to fix, and whatever it is you thought you were doing in this fixup patch has absolutely nothing to do with the suggested fixto the point where I end up missing the obvious and end up providing incorrect advice. For example, this coworker misconfigured an environment variable, and the program complained about it in very actionable terms. I got so caught up on my coworker's inability to follow basic instructions, I missed the trees for the forest: the correct fix wasn't to adjust that variable, but not to set it at all in the first place.

Unfortunately, being better than this is something that is expected of my role. I'm genuinely trying to help my coworker help themselves by pointing them to the diagnostics and encouraging at least a modicum of critical thinking instead of just spoon-feeding them the answer, though neither approach has really worked. However, their simple presence is now starting to cause irritation in me, and that's... unproductive. I wish I could have a real-time blacklist of people I never want to work with again and have it stick, but life isn't always going to be so accommodating.

So... how can I change this unproductive behavior of mine?

1
  • 1
    Comments are not for extended discussion; this conversation has been moved to chat.
    – motosubatsu
    Jun 24 at 10:17

13 Answers 13

144

So... how can I change this unproductive behavior of mine?

+1 for recognizing that your own behavior is part of the problem.

I'm genuinely trying to help my coworker help themselves

That's the ticket! However you probably need to try a more formal and managed approach with this co-worker. Doing this ad-hoc on a case by case basis obviously isn't working .

Here is one approach. (CW = co-worker)

  1. Schedule a 1:1 training session with CW. Go through the basics of debugging (read error message, unit testing, start with the simplest use case with known answers, etc) and make a check list together.
  2. Next time CW asks for help, go through the check list together. Ideally they should do it themselves, but chances are they won't. Amend and refine as necessary
  3. After 2-3 or three rounds of this, require the CW to have the check list done themselves before you engage. Be friendly but firm. No checklist: no help. Poorly executed checklist: do it again.
  4. If this doesn't work, escalate to the CW's manager.

BEFORE you do any of this, you should have a discussion with CW's manager, just to bring them in the loop. Let them know that CW needs help, that the current way of doing this isn't particularly effective and that you want to try this approach. Do not complain or blame. If the manager has any feedback, incorporate it. If CW's manager refuses, you need to escalate through your own chain of command, since this impacts your own productivity.

This approach to problem solving gives me the proverbial red mist

Hopefully having a complete plan of attack will help you to calm down your emotions. Don't engage when you are mad. Take a quick break (bathroom, "Sorry, I don't have time for this right now", "I'm busy, let's talk later", etc.) to remove yourself from the situation until you have regained control.

5
  • 78
    I always ask my juniors "Explain to me what the screen tells you"
    – Martijn
    Jun 22 at 7:06
  • 6
    The checklist you mention can also be a flowchart : xkcd.com/627 Jun 22 at 7:54
  • 2
    Good answer but OP should also clarify if it is OP's job with BOTH manager. As is, CW might get credit for his problem solving skills and OP might get some slack for doing something else than his main tasks.
    – lcrmorin
    Jun 22 at 10:39
  • Once there's a checklist in place, make a point during future issues to show where the problem would have been avoided if they would have followed the checklist. Clear associations between best practices and the penalties for ignoring them will make it very obvious to them where they can improve.
    – bta
    Jun 22 at 18:43
  • @Martijn Expected answers: "The computer says no.." or "The computer didn't do what I told him to do.." ;)
    – iLuvLogix
    2 days ago
27

So your mission is to help the other team succeed, but a member of that team needs far more help than normal, and is still just barely scraping by, and you are frustrated that the situation is not improving.

If things are this bad, the employee needs a formal training program, with a clear structure, goals, and accountability. Training members of other teams is likely beyond your remit, and even if you had the inclination and time, you have no means to hold that person accountable for their progress.

That is, the only thing you can do is to make this problem visible to the people who can solve it. Providing excessive help, aside from being frustrating for you, accomplishes the opposite of that, because it makes that coworker appear more competent that he is.

That's why I would stop providing excess help, and only provide what a reasonable person would require. Either he'll get his act together on his own, or his team will get its act together and start training him, or his management will get its act together, and move him elsewhere.

In addition, I'd make sure to provide most of my help in writing, preferably in a way that is visible to the rest of his team. For instance, by using an issue tracker, email with CC to other people who might help him, using the team chat, and so on. This accomplishes 3 things:

  • it allows him to refer back to your advice, so verify that he followed it correctly, did all the steps, and so on
  • it makes the amount of help visible to the rest of his team
  • it creates a permanent record of the amount of help provided, allowing you to prove that you did your job even if he should screw up

In particular, I would accommodate "often privately, via video-call" only rarely. In fact, their preference for private modes of communication that don't leave a permanent record might indicate that they are actively hiding their incompetence from their team (which would not be a very productive reaction on their part, but not all people are productive when overwhelmed by their job).

To conclude, let me briefly relate a personal anecdote. In my last job, I was in a similar situation with a new employee another team had hired, which needed about 3 times as much help as a normal employee. Whenever he would call for the 3rd time about the same issue, I'd just reply with "please do what I told you last time. I have verified that it works!". That lessened the volume of calls some. 2 months later, I heard the employee had been fired, and when I informally talked with their team lead and manager, they were like

Manager: Yeah, unfortunately we had to fire him. We found out that nearly all the work he did was done by other people he had asked for help

Me: I see. Yeah, he needed a lot more help than normal. I was like answering an email every day.

Manager: What, he asked you too? He went through our entire team! Man, if we had known, we'd have fired him earlier!

On his last day, the employee sent the following farewell note:

Thanks everyone for all the help. You are the best team I could have worked with, and I thank you for all your patience. I realize now that IT is not a job I am cut out for, and will be seeking employment in another field.

Wishing you all the best

Of course, an anecdote is not data, and your situation might be different - hopefully, it is! Still, it shows that if someone is not working out, it can be better to address this issue rather then prolonging the inevitable.

3
  • 17
    I'd also add - don't ever do things immediately for this person - it really helps to break the cycle if you say "oh, yes, I can look at that, on friday" rather than giving your views right there and then. It slows down their work, and encourages them to seek alternate solutions (which might be other co-workers)
    – lupe
    Jun 22 at 12:18
  • 5
    Another anecdote: I had an informal discussion with one of these help vampires on my team and suggested they spend a little more time investigating. They said it was quicker for someone to provide a solution than for them to troubleshoot. Spot on for just not providing them excess help so that the easy path for them is to figure it out on their own and built out their expertise.
    – Drudge
    Jun 22 at 23:41
  • 4
    Adding one more point: I've had a boss who's first idea of solving problems was to ask or call a person who could help him. I've made a point of not answering after-hours calls immediately (he was the owner, so he always worked well in excess of 40 hours). Sometimes I'd call back an hour or two later, sometimes I'd ask what he wanted when I got into work the next day. Usually, the answer was "nothing, I've already solved it".
    – jaskij
    Jun 23 at 15:53
9

So... how can I change this unproductive behavior of mine?

Learning to coach others is a valuable skill.

If someone's coming to you with a problem, is your first instinct to resolve the problem, or to ask how they've tried to resolve it?

I've had similar conversations several times with people when I was a content management system manager dealing with user frustrations. The gist of the conversations was:

Them: "Karl, help, this thing's broken!"

Me: "OK. Can you show me the issue you're seeing?"

Them: "Here it is" (they open the web page) "There should be a component here" or "The component's not looking right."

Me: "Can we walk through how you created it?" or "Can you show me the steps you used to create it?"

Them: "Like this..."

The conversation would either end with "Oh, it works now!" or me saying "Ah, I see where things aren't right. Tweak this."

If you can, ask really stupid questions as they're talking you through the steps.

In the example you gave - where the error message shows - ask them what the error message suggests. "This error message says it's missing a variable, how do we check it's still set correctly?" This phrasing suggests they might have done it right (even if you suspect they didn't) and "something" went wrong (which can happen) to unset it. It also guides them towards checking the error message to get the variable name and checking the variable's actually set.

Do that a few times and they should start to think problems through better. If nothing else, you get practice coaching people.

If it becomes too big a problem, a quiet word with your manager to see whether there's additional training the other person's manager can offer them would help. Manager to manager conversations can save a lot of headaches, I've had mine do that a few times when an issue's getting out of hand.

0
6

Senior devs helping with noobish questions during work hours is a waste of money for the company.

I would say something like "I am unfortunately very busy with project X" or "No, thank you" or "Person X may be able to help you" or "My manager has assigned me to this task, you can ask them to re-prioritize".

Or I would ask my manager if I should stop working on my assigned task to help my co-worker and, if the answer is no, relay that information to the co-worker so that the blame has been shifted.

Another option is to do the task badly, and late. They'll never ask you for help again. They might think you are incompetent, lazy or untrustworthy, but they are not your boss and it will stop them from asking.

Finally, there is an awesome technique called the "Wally reflector":

enter image description here

Source: https://dilbert.com/strip/2005-07-10

New contributor
Gantendo is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
3
  • 4
    I appreciate some questions may be answerable by peers instead of senior devs, but in the case where someone appears to be struggling I would think a senior dev is the right person to help. Jun 22 at 8:43
  • 2
    @mattfreake Certain questions can only be answered by a senior dev. But OP is not complaining about those questions. Knowing who to ask which questions can be difficult for inexperienced people.
    – Gantendo
    Jun 22 at 13:07
  • 2
    I think the questions are incidental. It's the fact this dev either doesn't know how to investigate stuff methodically or is not applying that. A senior dev seems a good person to address that, especially as they have the rank/experience to say "you should really be able to solve this yourself" Jun 22 at 16:54
6

Train them or lead them to training

I spent roughly the first 8 months at my current company as a borderline-help vampire to anyone and everyone who would provide it. From my perspective, the issue was that I was completely out of my depth - to the point where I didn't understand what questions to ask. This boiled down to a lack of training on the programming language I use (i.e. I straight up didn't know it, and they knew this when they hired me) and the fact that I took over for someone who created the infrastructure I was using without adequately documenting it (and who didn't overlap with me). I improved by asking a lot of questions early on and learning from them. Additionally, I was very forward with these lapses in knowledge in cases where "figure it out" didn't work, to the point where my supervisor understood that I wasn't just being lazy. This is to say, I got the help I needed but easily could still be that person, or could have quit, had I not been forward about these lapses.

The fact that this person is missing these obvious markers of an error sounds to me like they don't understand that the markers are there, or don't know how marker a leads to fix a. Are they new to the environment, languages, or infrastructure?

If they are failing to improve because they aren't being forward about their knowledge lapses, you (or a supervisor) could ask in no uncertain terms if they understand. If they say they do, plan a time to chat with them about the process, so you can assess what lapses are occurring. If they do not, set a time to teach them, and when you fix one of their issues, explain what went wrong and how you would fix it.

It's likely frustrating to you because they take up your time with their issues, but I think a little training would go a long way.

New contributor
Stehmansmith5 is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
1
  • 2
    We have a sizable project and both myself and a colleague, a few months in, asked to the 'introduction' again. Because on day one there is little to no real life context, redoing the introduction meant we could ask questions where we had a few blanks, in one, 30 minute session (as oppose to the initial two hours). If nothing else, it was good to ensure we, the developers, where on track, to build what the front end users, wanted. Jun 23 at 8:48
5

Produce a checklist they can follow.

When you next have to help them, don't try to solve the issue directly but try to come up with a process they can follow next time and document it. If the steps don't exist somewhere you can both see them, you're destined to go round in circles as seems to be happening.

When doing this, don't take shortcuts because you already know what the answer is, but go through the "unnecessary" steps together (or explain and document why you'd skip them). So maybe you know that particular error message is vague and unhelpful, demonstrate doing a search online and seeing the wide variety of results and together decide to move on to the next diagnostic step (rolling back to a previous version for instance).

Having done this, the next time they come to you, you can compare what they've done with the list. If it didn't work on the next error, then you know it needs more steps. If they've missed a step and not done it dillegently enough then point them to it and ask them to do it again.

Reinforce that investigating issues is not always quick and taking time is vital. It may be that their manager is putting them under pressure to fix things and they're making the call that it's more expedient to ask someone else who "knows" than work it out for themselves.

This can be a lot of work, but is in an investment in getting them off your back, and identifying whether they really can't do this work, or can be helped to.

4
  • 1
    How do I justify having them go through this "paperwork" without expecting others to do the same?
    – badp
    Jun 21 at 12:52
  • Which others? People who are helping him or others who are investigating things? Jun 21 at 12:54
  • I mean, other people asking me for help or support.
    – badp
    Jun 21 at 12:54
  • 3
    Maybe it's me, by I don't view it as a burden for them, it's a list of the things that you would check for if you were investigating. By having them written down you're just sharing that knowledge, in an easily accessible form. You could also share it with your wider audience "someone was asking me recently how to investigate something, so I thought I'd share my internal checklist that I follow". Jun 21 at 12:58
5

Is the problem that you hate dealing with this person, or is it that they're preventing you from doing your other tasks?

If it's the second, just let the person know what you need to do that day that is higher priority than helping them. If you want, you can give them some limited time box ("I can help you only for 15 minutes") or point them to someone else who might be able to help. This helps with a lot of people, because once they realize your time is not a boundless resource that they can use whenever they want, they start trying to filter their help requests before coming to you and seeing what they can figure out on their own.

It's good to actually know what your priorities are supposed to be; if you're not sure you can ask your manager what work is higher priority than helping X, and how much time in a day or week is appropriate to help X. Don't go on a tirade about how terrible X is, just ask them how much time they expect you to spend on it. A smart manager will read between the lines here and ask you what sorts of things X has been needing help with, and solve the problem in an appropriate way. A less observant manager will still give you a way of telling X to go away after a point, or at least give you an excuse for when your own work is not done on time ("well, I've been dropping everything and helping X, like you told me to").

If you really dislike the person, and would rather never help them regardless of work priorities, then you have to go to your manager and tell them you're finding it difficult to work with this person and it's making you unproductive. A normal manager will expect to hear compelling examples of what's so bad about it. They will also try to get the other person's story. So don't get personal with it, stick to the facts and let them speak for themselves. Also, although you have totally given up on this person, the manager will wonder if he can just convince you to deal with the other person, so don't expect them to just make the problem go away. Be patient, and don't look like you're the problem.

3

Software development is a continuous loop of issues that need to be resolved. Those issues sometimes require hours, days or even weeks of research and testing, yet it looks like your coworker gives up way too soon after facing one and goes on a search for someone "smarter". Perseverance is an important skill for a developer.

You either teach your coworker that he needs to spend 2x/3x/4x/whateverx more time on each and every issue he has or you can continue doing his job for him.

1
  • How is it a net benefit for the team for a developer to spend 2 weeks on a single issue that can be resolved by having someone with the answer spend 30 minutes with the coworker? Jun 24 at 15:32
2

I'd like to propose an alternative perspective, but since Stack Exchange is incredibly pedantic about answers, I'll answer your question by saying that putting an upfront investment to help this person learn how to debug new issues is worth a shot, BEFORE escalating to a manager.

Now for the alternative perspective. From a productivity perspective, it's better if this person is able to do work. Regardless of varying rate of work output, it would be better if this person is another thread that can do work to finish tasks. The problem as I read it above is that this person is spending a lot of time blocking work because he's asking for help, and this asking for help draws resources from other developers, which supposedly brings others down.

Firstly, I don't agree with the statement "the program is telling you whats wrong". I think that's an incredibly simplistic reduction of what happens in normal debugging. Many times, an error that's surfaced can be a result of myriad possibilities. Getting an ENOTFOUND exception for example isn't trivial to debug, especially if you're new to working in node or working with services, which is extremely common for new developers. And this is just 1 example, I've dealt with 1000s of errors across all the projects I've worked in, and i would say probably < 10% of the errors were clear cut, as they were related to unit tests. A lack of understanding on how to debug an error usually results from not understanding the system or the call flow, and that's incredibly common with junior devs and not necessarily indicative of a performance issue. In college, you don't deal with a lot of the errors that you get in a corporate environment. Your issues are extremely isolated, and your codebase is like 10 files max vs 100s of files across multiple microservices. Furthermore, many corporate environments have their own internal tools and patterns that make it difficult to just simply google the answer for. The company I work for has its own internal build system for example which is a beast in of itself that even mid level devs have to be onboarded to and still have trouble with.

While a dev should have independence, this independence isn't a personality trait that's automatically given to everyone, and even if it is, there's bound to be situations in which it doesn't really surface simply because of deadline pressures or other issues. If I'm pressured to finish a code review by the end of the day, and I'm running into a really strange build issue that I can't google because it's internal to the company, and I have to a Depth first search on a 100 different internal docs to learn about the build system to fix this one issue, I'm going to opt for the easier route and ask someone.

As a senior dev, you should be in the position to provide assistance and guidance. If a problem is genuinely obvious, then rather than seeing "red mist", just point out that "hey, maybe its written in the error." Walk through how to debug an error with that person. Assuming that instructions are already written or there are docs isn't a good approach IMO because docs can be unclear or outdated, and people absorb information differently. Going back to my example, the internal build system we use is so complex we have a dedicated wiki for it. But the wiki is so complicated, that 1 dev in the company made a video on the system distilling the important parts and explaining it differently, which garnered a lot more positive support than the wiki. And even in that video, the dev states that the wiki is confusing and verbose.

Finally, consider your relationship with the coworker. You might not care about how he/she views you or working with him, but your interaction with this person will shape both his output and his impression of working at this company. I've been in a situation where I asked a senior dev for help, and he rebuffed me in a way where I basically never spoke to this person again. To be fair, I didn't do enough research at the time, but sometimes when you're in the midst of the problem, it's not clear what you're supposed to look at.

the end goal should not be reprimanding this dev nor should it be getting pissed off every time he asks you a question. If this dev is junior, this honestly sounds partially like an onboarding issue + lack of knowledge about how to debug corporate systems because of misalignment between professional development and school development, or its misalignment between what the dev is used to and what dev processes are like within your company. Getting angry at him only make things worse.

You may not have ever been in the position where you needed help from a senior engineer when you were a junior, and that's good for you. But others might have a different starting point than you. And as someone who was that kind of junior, and is now a fairly strong SDE 2, I benefited far more from the people who sat down with me and took time to explain things than from the ones who rebuffed me or just saw "red mist" and threw links to wiki docs or READMEs at me that they clearly have not read before.

New contributor
Jeremy Fisher is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
7
  • 3
    The fact that the text of an error message may not be the whole story is no excuse for failing to read the message in detail in the first place.
    – Ben Voigt
    Jun 22 at 16:20
  • 1
    That's just completely untrue. Errors are constantly masked in tons of different ways. I recently got a database mapping exception and the underlying issue was a failure in a conversion method that I only found by debugging a unit test that went into dependency code I never touched before. If a junior dev ran into that I would find it totally reasonable if they asked me about that. Jun 22 at 16:22
  • 2
    "I would find it totally reasonable if they asked me about that"... so would I, if they first had read the error message, captured a stack trace, and explained what their code was trying to do when they got the failure. Asking a co-worker for help needs context, observed, and desired behavior just as much as any debugging question asked on SO does.
    – Ben Voigt
    Jun 22 at 16:28
  • 1
    I agree with you, but we don't know what the junior dev actually provided to OP. What we are getting is a one-sided view of a pissed off dev. To be honest, I find it more likely that the dev presented the issue as "I got this error, here is a copy paste of the stack trace, I was expecting this. Do you know what's wrong?" And I'd argue that's reasonable. Consider also that lack of knowledge also means lack of understanding what context is relevant. I'll admit I am biased cause it sounds like OP is just stressed out at someone he doesn't like asking him questions. Jun 22 at 16:30
  • 1
    "From a productivity perspective..." This is not true. If person A can do 10 things/hour, and person B can do 1 thing/hour IF they have 30 minutes of help from A, then A = 10/hour and A+B = 6/hour. If B will become a net positive on the team then it's still worthwhile to train them, but some people never get there. (Also, note that even if B slows down and takes several hours to do 1 thing figuring it out on their own, the net is still higher than them requiring 30 minutes of A's time.) Jun 23 at 15:48
1

Solve the problem and not your co-worker

You tilt because this is a troublesome worker. If you are responsible for the worker's output, it's reasonable for you to focus on how they are troubleshootng. It's also reasonabe for a decent person to want to help people, but this has passed that. If your role is getting the product working, keep your focus on that and ignore the things this worker does wrong.

1

The first question: Is the helpleech one of your reports, or do they report to someone else?

If they report to someone else, you (and the rest of your team) need to re-direct the requests to the proper channel. Only when you (and your team) are formally tasked with helping people outside of your team should you permit this.

Second, whether this behavior is allowed or not, document every instance of it, if for no other reason than to include it in any end-of-day or end-of-week reports on work done for the week. That way if helping causes you (or your team) to miss deadlines (or fall short of some other expectation), the reason will be part of the record.

Third, talk to whoever is responsible for training the helpleech. Whatever that person is doing is clearly not succeeding. If there is no such person, that's the problem.

If the problem persists long enough, HR will (or at least should) get involved, and you will need your own ducks in a row at that point.

1

It might be they lack confidence and now they have become use to asking you.

Could you 'timebox' non-urgent help, so you both have expectations on the day. Ask them to write notes, as if they were asking on SO and run though ways you fix solutions, such as regular breaks to clear the mind (I sometimes walk the dog for 10 minutes if I am stuck). "Desk time does not equal work time" is a mantra to me!

Lastly, have an informal chat (tell them about a pet you have etc..), a catch up on what is going on in life, my performance (and confidence) dropped through the floor when there was a person issue, you do not eat/sleep so your tired, so you cannot think, and it spirals. Sometimes you just need a nudge and a cuppa.

Working out the cause is key here.

New contributor
indofraiser is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
-4

Meditate on the question for 10 seconds. Give a brief and generic guideline, then move on.

New contributor
Samie Bencherif is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .