3 ms·

I have a coworker who is similar to this. Not so much "do my work for me" group, but very much in the "will ask you for help and then turn down anything you tel

by dvtrn 8y ago

I have a coworker who is similar to this. Not so much "do my work for me" group, but very much in the "will ask you for help and then turn down anything you tell them, while still getting it wrong". Let's pretend our infrastructure is a home kitchen with a failing microwave oven. "Hey, why isn't this button on the microwave working?" "Because that's a refrigerator, not a microwave" "No I KNOW it's not a microwave, but how do I get it to heat up my lunch?" "Refrigerators don't heat things..." "Sigh I know how microwaves work, why isn't THIS one working?" I really wish I were being hyperbolic about this, but I'm not. Lately I've taken your tactic and just throw them keywords and proffer that I'll help them out when I can break away from other items. It hasn't failed that after a couple of cycles they'll say "Hey you were right about that microwave" and in my mind I'll say "no kidding". On a darker note: there's quite a few of us who don't think this engineer is long for the company (they were hired only a few months ago).

bigiain 8y ago
Personally, I'll cut "the new hires" a lot of slack. "A few months" is way within the "still trying to work out who the fuck they are and how they fit in". If they haven't bailed on the company in ~12 months, but are still asking the same lack-of-understanding-questions they've been asking all along, that's when I redirect my effort/energy elsewhere and dial my help back down to just offering relevant search keywords and a "sorry, I'm busy, maybe ask my boss to schedule a meeting after the end of this sprint if you still need help?" response (In writing. With an auditable paper trail...)
- dvtrn 8y ago
  Which is something I haven't yet had to do as it seems a lot of relevant people are picking up on this and there are mumblings going on of this person getting the axe soon. There have been more than one occasion where I'd find a potential solution to an issue this engineer is having, send it over to them as a helpful gesture-and I'd watch as they pull up the link, scroll immediately to where the commands are, bypassing every bit of text that gives insight into what commands are about to be ran, dependencies to interrogate before, or considerations that may be unique to a specific instance, and start slapping away at the keyboard without a clue in the world what the command they're entering is actually going to do. I think it's less a skills gap but an issue with someone who is baked into their ways and hasn't been shaken loose from them on a more functional team.
munk-a 8y ago
So the company you works at wants to pay people to make them money. When people start at a new job there's often a ramp-up time until they become productive and usually a second period until they're stable enough to lead others, but if someone is stuck in that negative efficiency state then it is something you should pass up the chain. If you're an experienced dev who is spending four hours a day holding the hand of someone new to the company that's an investment but if it's still going on months later then your manager will want to help the situation so that you can use your own time productively. It's a hard situation and I've been lucky that I haven't been stuck with anyone who can't overcome that initial learning phase, but if you find yourself there you should try and unload the problem to people more HRy and save yourself the stress. (All the above, BTW, is not to imply that one-person rockstar programmers are a thing (they aren't) and skills vary, I am only talking about extreme scenarios)

by dvtrn 8y ago

bigiain 8y ago

Personally, I'll cut "the new hires" a lot of slack. "A few months" is way within the "still trying to work out who the fuck they are and how they fit in". If they haven't bailed on the company in ~12 months, but are still asking the same lack-of-understanding-questions they've been asking all along, that's when I redirect my effort/energy elsewhere and dial my help back down to just offering relevant search keywords and a "sorry, I'm busy, maybe ask my boss to schedule a meeting after the end of this sprint if you still need help?" response (In writing. With an auditable paper trail...)

dvtrn 8y ago
Which is something I haven't yet had to do as it seems a lot of relevant people are picking up on this and there are mumblings going on of this person getting the axe soon. There have been more than one occasion where I'd find a potential solution to an issue this engineer is having, send it over to them as a helpful gesture-and I'd watch as they pull up the link, scroll immediately to where the commands are, bypassing every bit of text that gives insight into what commands are about to be ran, dependencies to interrogate before, or considerations that may be unique to a specific instance, and start slapping away at the keyboard without a clue in the world what the command they're entering is actually going to do. I think it's less a skills gap but an issue with someone who is baked into their ways and hasn't been shaken loose from them on a more functional team.

munk-a 8y ago

So the company you works at wants to pay people to make them money. When people start at a new job there's often a ramp-up time until they become productive and usually a second period until they're stable enough to lead others, but if someone is stuck in that negative efficiency state then it is something you should pass up the chain. If you're an experienced dev who is spending four hours a day holding the hand of someone new to the company that's an investment but if it's still going on months later then your manager will want to help the situation so that you can use your own time productively. It's a hard situation and I've been lucky that I haven't been stuck with anyone who can't overcome that initial learning phase, but if you find yourself there you should try and unload the problem to people more HRy and save yourself the stress. (All the above, BTW, is not to imply that one-person rockstar programmers are a thing (they aren't) and skills vary, I am only talking about extreme scenarios)