I find senior developers guilty of the same mistake; that's why I think this is a sign of being overwhelmed instead of "doesn't care."
My reaction is always the same: When I hear "doesn't work", I ask: "What error message do you get?" (and I try to be polite).
The answer will then tell me whether the person needs to vent some steam before they can start thinking again - if someone is in this state, no advice in the world will work since they simply can't listen; calm them down, first.
If they were just lazy, insist that they go back and read the error message. If you think they should know what it means/how to solve it, start asking questions: like "What do you think could cause this?", "What does
foo mean here?", "What did you change right before the error happened?" Asking questions is a good way to kickstart someone else's brain since most people try to be helpful when asked. So this is received as positive support even though you don't actually "help" them.
If they simple don't understand what is going on, sit with them and explain to them how to fix the error. I tend to have them fix the error themselves for two reasons:
- The brain remembers things better that you have done yourself (instead of watching someone else do it).
- If they don't understand the explanation, that gives them a chance to ask.
If I'd fix the error myself, there is always the danger that they now have working code but don't know why.
PS: This goes to all the senior developers: Write better error messages. A good error message explains how to fix a problem; a bad one is a variant of "There were errors."
So instead of
File not found, say
File ...path... not found. Instead of
Glabarfel couldn't be initialized, say
Glabarfel wasn't initialited properly; missing Foo. See http://.../docs/setup/glabarfel/foo.html for details.