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.


5 Answers 5


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.

  • 1
    This! Having them wait is the best. They should by far be smart enough to figure minor errors out themselves. If not or if they start to do something different, they may be the wrong ones for the job.
    – valenterry
    Commented Dec 10, 2014 at 12:06
  • 3
    I would suggest waiting much more than 15 minutes. In 15 minutes, it easy enough to just go read your favorite time-wasting web site. Make it more on the order of one or more hours. Commented Dec 10, 2014 at 14:19
  • 1
    @user1118321 the kind of person who doesn;t have enough initiative to read and act on a simple error is the kind who will spend all day surfing the web and then blame you for their lack of progress.
    – gbjbaanb
    Commented Dec 10, 2014 at 14:31
  • I forgot to add, you don't say: "wait 15 minutes", you say "I'm busy, please let me finish x, then I help you". 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. Commented Dec 10, 2014 at 15:14
  • @pietromenna Could you add that to your answer? It adds important nuance.
    – JvR
    Commented Dec 10, 2014 at 16:17

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.

  • Great one, during my examination time (3 years in Germany) my trainer was always going with me for each error seperate and took the time, that I needed to understand and fix it. It helped a lot and is way better than, "Well, you will find out soon"
    – Knerd
    Commented Dec 10, 2014 at 15:22

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.

  • This is great advice. By documenting it themselves, they have to think through why the solution worked. I love it! Commented Dec 10, 2014 at 14:22
  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.

  • Also check Aaron Digulla's answer for a different perspective/focus to this approach.
    – JvR
    Commented Dec 10, 2014 at 16:21

"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.

  • 6
    This is some of the worst advice I can imagine, and is the reason why people think computer and IT staff are arrogant jerks. Please don't do this. Show some compassion, but let them know if they're wasting your time. You don't have to be insulting, though. Commented Dec 10, 2014 at 14:20
  • 1
    @user1118321 this is not about normal people requiring help, the OP talks about people who have refused to help themselves in the slightest. If they were on SO, gnat would be posting his "sharing you research helps everyone" comment. This isn't a "RTFM n00b" response, its a way to tell a developer they should have at least attempted to fix it themselves and that you're not impressed that they've involved you before doing that.
    – gbjbaanb
    Commented Dec 10, 2014 at 15:05
  • I fear it's more likely that complaints about unhelpfulness will reach your boss than that it will be taken as an opportunity for reflection. This approach may or may not be effective--I wouldn't know--but it may also have consequences for you.
    – JvR
    Commented Dec 10, 2014 at 16:12
  • @JvR in my experience, you have 3 choices: 1. ignore them and then it turns into your fault (as per the other answer). 2. always solve it for them, and then always have to fix their little issues. 3. do the above, then if you get pulled up on not being helpful, you can explain what the "problem" was and it becomes obvious they are the ones shirking their responsibility. Of course - this doesn't apply to people who have real problems. I have to say, any dev who can't fix his own compilation isn't much of a dev.
    – gbjbaanb
    Commented Dec 10, 2014 at 16:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.