
How do you judiciously help someone whose work isn’t very good? - jseliger
http://jakeseliger.com/2015/02/25/how-do-you-judiciously-help-someone-whose-work-isnt-very-good/
======
kleer001
Ok, that works for a Teacher-Student dynamic in a creative writing course...

Would love to read an article with the same question and a different context.
Namely work. What do you tell a coworker, working on the same project, that
keeps making "simple" errors and comes to you to fix them?

~~~
MaulingMonkey
I touched on this as a rebuff to the "Why Rockstar Developers Don't Ask for
Help" thread [1]. You might find the rest of that discussion interesting as
well, even though it's focused on the other side of the coin (making errors
and _not_ coming to you to fix them.)

But to answer your question directly...

> What do you tell a coworker, working on the same project, that keeps making
> "simple" errors and comes to you to fix them?

There's two potential primary causes here that I've encountered.

One is where your coworker is unable to identify their own simple errors.
Teaching them how may be as simple as talking out loud as you work through
your own problem solving process, or explaining how you were able to do it
yourself. It can be much harder than this though. Sometimes just letting them
struggle with the problem on their own for a bit might be your best option.

Second is where your coworker simply isn't attempting to identify their own
simple errors. This isn't necessarily borne out of laziness - but as a matter
of what they first think of when they go about solving a problem. My usual
rebuff is this: "Let me finish up [whatever I'm in the middle of | this high
priority thing] first, and then I'll swing by and provide a second set of eyes
if you're still need it."

They usually no longer need it. Or it's not a simple problem. Or I'm happy
enough to rubber duck for them on the few occasions when they just can't spot
what they're normally capable of spotting, right in front of them, staring
right at them.

I've been fortunate enough not to encounter people outright refusing to try
and solve their own problems within the workspace. When I've encountered it in
other venues (forums, chatrooms), I eventually point them to such articles as
"asking questions the smart way" et all [2], and attempt to force the issue -
I'll stop directly pointing out the problem, and instead try and coax them
through the problem solving process.

Sometimes this works - if the only way to get an answer out of me is to go
through the motions of the problem solving process, they'll start to noticing
the answers on their own without me. Then they start to realize it's faster
for them to go through the problem solving process on their own.

Other times, they're simply unwilling to go to that effort - in which case I
don't put forth the effort to continue helping them. I'm too busy to help them
and say so. If they persist to the point of annoyance/too much distraction,
even if I tell them to knock it off, I'm willing to /ignore, /kick, or /ban
them - presumably, in a workspace, this would eventually get to the point
where management gets involved. The tools there would be reassignment (beware
just shifting the problem around), formal warnings (sometimes successful as a
wakeup call), or finally firing them (or quitting.)

[1]
[https://news.ycombinator.com/item?id=9082432](https://news.ycombinator.com/item?id=9082432)

[2] [http://www.catb.org/esr/faqs/smart-
questions.html](http://www.catb.org/esr/faqs/smart-questions.html) \- I've
read this a few times myself and can strongly recommend it, even if you
already ask smart questions :)

~~~
kleer001
Excellent, thanks!

