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, e

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 :)