How can I encourage people to read error messages? [duplicate]

Question

I was wondering if there are some good ways to encourage people to read error messages when the compilation fails.

People (especially) the junior ones usually ignore the error messages and just ask for help. I want them to be better and have run out of ideas. These are what I have tried.

1. I tell them to check error messages when compilation fails.
2. I sit and check the error messages with them.
3. When they ask me for help, I ask if they have checked the error or not.

Please let me know if you have similar experience and how you deal with it.

Answer 1

Do not help right away. Make the junior colleague wait for at least 15 minutes, after one or two of this 15 minutes cycles, he/she will start to look at the issue on his own. Just don't say directly "wait 15 minutes", use something like "I'm busy, please let me finish x, then I help you".

If you help him immediately, this is the shortest path he has for the solution of the problem, then of course he will use this path. But, instead if you say, I will help you and solve the issue, but please, wait for 15 minutes before I can help you, during this time he will stare at the screen to see what he might try on this "wait time", he will probably look at the error messages on his own. :-)

If they do not start to look for the error for themselves, then you can say the person lacks of initiative or experience. If the problem is initiative, it is hard to solve. If it is experience after one or two analysis together, they should start to figure it out.

Answer 2

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:

1. The brain remembers things better that you have done yourself (instead of watching someone else do it).
2. 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.

Answer 3

This is a bit of a behavior modification question, but needs to be addressed in a development team environment. Do your junior developers have to do support or any type of bug fixing? Ask them how they feel when someone just tells them "I got an error" with no other information. We can avoid all the name-calling that probably goes on when they have to deal with stupid users.

When they tell you there is an error, ask them what the error message was. They can include it in an email or register in some sort of bug tracker/team information/wiki system. This way, others can look up a solution for this error message when it reoccurs.

You need to be diligent. Ask for the message. Ask if they looked up the message for previous solutions (Just like you tell your users.). You don't want to be perceived as not helping, so if it is a new problem, you should try to address it as conveniently as possible. Compliment those who contribute to the documentation of these errors.

As a team, you need to address the problems of interruptions. It may seem more convenient to just ask the person who knows the answer right away, but getting pulled away from your code create other problems and delays in the long run. The junior developers need to learn this.

Answer 4

1. I tell them to check error messages when compilation fails.
2. I sit and check the error messages with them.
3. When they ask me for help, I ask if they have checked the error or not.

From what you're writing, it seems like your juniors either don't really understand your solutions and aren't able to apply them in other situations that are not 100% identical to the previous one, or theyve learned that you're the magical solution fairy and that bugging you is the quickest way to make their problems go away.

Luckily, most of the time, you can help them in the same way: lead them with analytical questions rather than with your knowledge.

• "What seems to be the problem?" Sometimes, just trying to explain the problem to you will make the answer dawn to them. At the least, it allows you a look into their frame of reference and, not to be underestimated in importance, tells you what they perceive the problem to be.

• "What does the documentation/Google/whatever say?" Do assume that they at least tried to figure it out. If they haven't, stay with them for a bit while they do look it up (don't jump ahead and give them the solution). If the solution is there, give them a friendly goodbye, happy to help, and go back to work. If not, or if it's not really applicable, move on to the next bit:

• Walk them through finding the underlying issue. Function already defined? Ask them where else the function may be defined; point them to search functions if needed. Undefined variable? Ask them to verify where they defined it, and scrutinise the spelling. Unexpected if? Is this really the start of a new statement? Did you end the preceding one?

  (There's no need to be pedantic or go Aristotle's Teachings 660 on them, but you do need to guide them through the required steps of finding a solution, and you need to be open and patient.)

Once you have found the source of the problem, hopefully the solution is trivial; if it's not, then your junior developer hit an actual snag that's not obvious to the uninitiated.

But doesn't all this take longer than your previous approach? Probably. The principles of the approach are three-fold:

1. You teach people how to find a solution to their problems. In particular, that analysing feedback from their actions (error messages) is crucial to finding a solution. Not only will this improve their independence, but their analytical thinking as well, ultimately making them more at home in an automated environment or, at the very least, less likely to actively hinder others.

2. You don't assume that they're idiots or lazy; this will make them more likely to listen to you and follow your example. Approach their issue as an actual, bona-fide problem that needs to be solved. Who knows, maybe it is.

3. You help establish a cultural (team) standard that it's okay to ask for help in solving issues that you can't figure out, that you're willing to coach and help them find and learn a solution, but also that you're not the office's magical solution fairy, and that there has to be at least a token effort from their side. Trying to figure out the information you have, such as an error message, is the most basic step.

Answer 5

"When the compilation fails"... in such cases, I'd go over to them as if to help with a brand new, difficult, requires-experience error... I'd go through the basic steps of "show me" and then I would read the error message that was displayed by the compiler, and if it really was a case of do-what-the-error-message-says, I'd put on my best "you are a child" face, ask them why they couldn't have read that themselves, then and walk away.

You can't really not help them when they ask, but you can be disparaging about it if they are wasting your time.