9 ms·

Read the error messages. Reread them. Extract every piece of information from them. Never close an error popup without having read and understood what it means.

by C4stor 8y ago

Read the error messages. Reread them. Extract every piece of information from them. Never close an error popup without having read and understood what it means. Always read stack traces when you're blessed enough to have them. 100% of the juniors (and an awful lot of seniors) I've ever trained simply ignore those and then come ask for help debugging. 99% of the time, the explanation for their problem is literally the first line of the stack trace/error message/whatever is red on their screen. If you successfully adopt the mindset of "whatever the computer is telling is true from the computer point of view, so I'd better make sure I've read it" instead of "Anyway, I'll try something else and run again", you'll debug 10 times faster. And since debugging is a good part of the job, you'll be a lot more productive.

donkeyd 8y ago
Definitely this. Reading logs is a skill. It's pretty much the same for debugging. I notice the juniors often start to look at where the problem may be. I usually try to first look where it isn't, so I can drill down to where it actually it, in stead of just looking at code and hoping to find what's wrong.
- duncanhill 8y ago
  Totally concur, that's very similar to the method I explain to folks when they ask how I go about debugging. I've always visualized it in my head kind of like a binary search tree, or maybe the bisection method in math for finding roots. I want to think about as little code as possible, so I take steps to cut the problem space down as dramatically and quickly as possible. Plus, the less I have to think about when debugging the less likely I am to end up with an actual headache.
alevans4 8y ago
I agree that this is one of the most useful things that you can do and one of the most commonly overlooked for whatever reason. I can't underestimate the number of times I've worked with someone who is looking in seemingly random places to solve an error instead of tracing backwards from the error message in front of their face.
ryandrake 8y ago
Related: Read the official documentation. I can’t count how many times junior folks have asked me things like, does FooBarFactory constructor take an array of ints or floats? Well, what does their documentation say? Sometimes the official documentation is crap and that’s a reasonable question, but usually the answers can be found in TFM.
- ggregoire 8y ago
  I noticed a similar trend in JS dev: asking/looking for (video) tutorials instead of reading the official doc. Even when the doc is good and quick too read (React, Redux, Vue, etc).
  - charmides 8y ago
    Related to that, usually I am a little faster finding answers to syntax questions on SO than in the documentation, even when the documentation is good. So I'm glad that people have been asking those basic questions on SO.
  - baggsie 8y ago
    I tend to grok things a great
  - AYBABTME 8y ago
    Yeah, it's a bit weird why people have this expectation to reach for tutorials by random person X instead of looking for the official docs. I can't count the number of time someone asked me which tutorials to read to learn Go, but hadn't even considered reading the docs.
axpence 8y ago
100% agree. Likewise, I think adopting a "how can I create a stack trace/error message" mindset is incredibly important. Can you add a breakpoint to a certain piece of code? Could you add a try/catch statement somewhere to catch the error? Far too often good engineers do not have an "active" mindset in hunting for stack traces/error messages, instead, they wait for them to fall like manna from heaven.
- Agathos 8y ago
  Raise your hand if you've ever created an insert/update database trigger that explodes when that it sees that one bad value you've been investigating, just so you'll have a traceback that points to the offending code. (Hopefully only in your development environment.)
JepZ 8y ago
In general, I agree that juniors tend to skip useful information, but it depends a bit on the technology you are working with. PHP, for example, was known to report the error for the line after the one you forgot the semicolon at or at the line after the last line of the file when a parenthesis was missing somewhere. While there is a reason why it did so, those are error messages which are quite hard to understand the first few times they occur to you. Nevertheless, those lousy error message should be exceptions nowadays, and if you are using decent technologies, the chances are much higher, that you just didn't read the error message not careful enough to understand the problem.
- C4stor 8y ago
  My comment is a bit extreme in its tone indeed ! It's just that it's the advice I've given the most by orders of magnitudes, and I'm still amazed (and a bit weary) it's worth even mentioning. And to make it stick, I've removed any nuance of it...
rand_r 8y ago
I think a lot of the time people are perfectly capable of figuring out the issue on their own, however they ask for help for social reasons. Getting another person involved in the problem is way more fun, and creates a bond between both people.
- dlivingston 8y ago
  I've observed this a few times, too.
- klohto 8y ago
  When you’re messaging me 20 times a day about simple exceptions like “X gem is not installed” (Ruby) and asking me what to do, then it has an opposite offect of creating a bond
  - petepete 8y ago
    For non black and white problems it makes more sense though. Discussing the best approach for something complex, for example. Timing is important though, you don't want to intrude, interrupt or distract.
andy_wrote 8y ago
I really like your last point "whatever the computer is telling is true from the computer point of view". In a surprising number of coding interviews that I've conducted, I've seen a candidate write an incorrect solution that generates an exception and then attempt to figure out the error almost on first principles, rather than actually reading the exception carefully and thinking about what coding errors could have caused it to happen. The exception message is a _huge_ hint! It's a red flag to see someone try to debug without paying attention to it. Conversely it's very positive to see someone encounter one and then think carefully about it. Writing an incorrect solution but then testing it out and showing the ability to debug and fix it systematically and expediently is no worse than getting it right on the first try, in my book.
- fhood 8y ago
  It isn't just a huge hint, most of the time it tells you exactly what the damn issue is. This discussion is blowing my mind. I am honestly speechless. IT GIVES YOU THE LINE NUMBER AND THE FUNCTION CALL AND THE REASON! Why would you ever even attempt to debug without parsing it?
  - dsr_ 8y ago
    And in the opposite direction: remember when you are writing error messages to include all the relevant details, and never ever write "this shouldn't happen" or "document later".
    - fhood 8y ago
      What about, log_panic("If we have somehow managed to hit this code path, this project if FUBAR. I would recommend giving up and starting over.")
      - m_samuel_l 8y ago
        That's annoying but fine as long as it's unique and you can grep it in the codebase.
PurpleBoxDragon 8y ago
Eventually you'll learn what errors can be ignored, what are useless information, and which ones are sending you down a path that will waste time. But only start skipping and skimming once you've learned what to look for, and always be prepared to toss out the old knowledge when working on a new system. Also, when you have far too many logs, reading in reverse chronological order works most of the time, but not all the time. Generally the last error you are looking at is the error you want to find and fix, but always consider that sometimes an earlier error that seems unrelated can be the reason a later error is even possible.
ljm 8y ago
This is a good insight. Many a time I've offered a fix to a bug and the response was "how did you figure that out?" My answer was that I looked at the error message and then, if it was available, scanned the backtrace to figure out which files/method calls were involved. Otherwise (particularly with JS), I set up some breakpoints in the browser to help visualise things better. I've come across plenty of senior developers who ignore what the machine says. The thing is, most bugs aren't solved through intuition, so approaching the problem as if your gut feeling is completely accurate is going to turn a 10 minute debugging session into something that could last a full day. As, in my experience, it once did.
Aeolun 8y ago
Also great advice for a senior. Great advice for anyone really.
imgabe 8y ago
Ok, I'm strictly a hobby developer so I don't really have co-workers to go ask for help. Do people really not read error messages? That boggles my mind. How would you ever figure out what went wrong? I mean, how could anyone ever learn to program well enough to get a job as a professional programmer without knowing to do that?
- dx87 8y ago
  A lot of programming jobs just need someone who can follow directions, not someone very skilled. It's the digital equivalent putting together IKEA furniture instead of being the person doing all the design work to ensure things fit together and the directions are simple to follow. The most common way I've seen people try to figure out what went wrong is sprinkling stuff like "console.log("Here1"), console.log("Here2") throughout the code until they figure out which "Here" statement wasn't printed, then they start making random changes to values until the error reflects the changes that they made, then they check stackoverflow, if there aren't any results, they'll paste the error message with no context, having learned nothing in the process. It's pretty common in any field where you can get by knowing "what" to do, vs "why" to do something. I've seen the same thing teaching Linux classes where someone throws up their hands and gives up because they tried to cat a file and it said "error: no such file or directory", but they just saw "error", and decided it was too difficult.
- jetti 8y ago
  There are certain people that just don't have developed critical thinking skills and will shut down the minute something goes different than expected. I have dealt with a few of those types of people in my career and it is incredibly frustrating. The best thing you can do for them is not to help them in the way they want, by giving them the answer, but by making them do some of the grunt work on their own before they even come to you. I ask a lot of questions about what they are seeing and if they can't answer them then I make them go back until they can. Simple things like "what have you searched for regarding this", "what does the error message say" in order to get them in the habit of actually starting to look into their own issues.
- PeterisP 8y ago
  The obvious answer is they don't figure out what went wrong, they tweak the program until the problem goes away for a while.
fisherjeff 8y ago
This is excellent advice, and I would suggest reading warnings (e.g., compiler warnings) as well – even if they don't indicate a problem, understanding why a warning is thrown is often a very worthwhile exercise.
beardbound 8y ago
I work in QA and I wish more developers thought this way. Also run your code before hand off. Please. If I had a nickel for every time I got a user story or bug to validate and it immediately crashes then I would have a bunch of nickels. Which wouldn't be super helpful, but still. Please at least run your code, or ideally you should have CI/CD with unit tests, but we all know that isn't always the case especially in legacy Enterprise software.
- debaserab2 8y ago
  It's easy to make the assumption that developers haven't ran the code at all, but I find in reality that's rarely the case. In my experience it almost always has something to do with an unexpected environment variant. It's very easy as a developer to get so comfortable with the "happy path" of navigating code that you forget to look outside of the happy path when devising your test cases. It takes time to learn to identify the test cases you're not regularly exposing yourself, and these test cases are often ones not described in a requirements or specs doc.
  - rcollyer 8y ago
    As a QA dev, myself, I run across this occasionally. For a recent bug, the dev couldn't reproduce it, yet I could consistently. The difference: the width the window we were using; he was using the default, I was not. Most of the bugs I run into are not config dependent, so it is always surprising when one is.
  - egfx 8y ago
    This! I spent the first half of my career in QA. This second half in dev. Coming from QA I'm very meticulous about everything and yet as soon as it leaves my hands something comes up. This is why I'm a big proponent of QA. I had a chat with someone who was pretty much dismissing QA because they had the mindset of I'll just test it or my cofounder will help. It's terribly surprising what goes down outside the confines.
- phaedrus 8y ago
  As a developer this bugs me too. I once was team lead on a team which had two developers (bad hires) who seemed to believe that it was only their job to write the code, someone else's job to run it and test it. I started putting "and test the code" in the tasks; a team member successfully lobbied our manager that that was another task. So now I had to write 2x as many tasks, and the predictable result happened: the developers who didn't test their own code grabbed all the "write the feature" tasks and banged them out rapidly (easy to do when you don't make sure it works!) The more experienced developers were left to pick up the "and test what you wrote" tasks, which really amounted to rewriting the bad code. Then management said, "Why are you (senior developers) wasting so much time testing code? It generally seems to work and we can always fix it later." There was just no way to win. I'm glad I don't work in that environment anymore.
byron_fast 8y ago
Don't think, just set the halt. https://ronjeffries.com/xprog/articles/practices/pracjustsetthehalt/ https://ronjeffries.com/xprog/articles/practices/pracjustset...
btschaegg 8y ago
An addendum to that: Design your error messages. When dealing with exceptions, catch/wrap the exception (e.g. using InnerException in .NET) and add important information if necessary. You'll be glad you did six months down the line, when the exception actually pops up and you instantly know how to reproduce the bug (perhaps because you know the id of the business object involved). Edit: Also, use understandable text for error messages. Don't go around talking about threads/sockets etc. unless they happen on that abstraction level. The user should see business-level errors, so they know what happened in the business domain and why ("we don't know why, this shouldn't have happened" is a reasonable answer there, too). Edit 2: I just thought of Git's "plumbing vs porcelain" metaphor. Abusing it slightly: It's much more pleasant to be notified of an error by a red light instead of standing ankle-deep in sewage. I guess that metaphor breaks down a bit, since toilets more often have the latter than the first :)

by C4stor 8y ago

donkeyd 8y ago

Definitely this. Reading logs is a skill. It's pretty much the same for debugging. I notice the juniors often start to look at where the problem may be. I usually try to first look where it isn't, so I can drill down to where it actually it, in stead of just looking at code and hoping to find what's wrong.

duncanhill 8y ago
Totally concur, that's very similar to the method I explain to folks when they ask how I go about debugging. I've always visualized it in my head kind of like a binary search tree, or maybe the bisection method in math for finding roots. I want to think about as little code as possible, so I take steps to cut the problem space down as dramatically and quickly as possible. Plus, the less I have to think about when debugging the less likely I am to end up with an actual headache.

alevans4 8y ago

I agree that this is one of the most useful things that you can do and one of the most commonly overlooked for whatever reason. I can't underestimate the number of times I've worked with someone who is looking in seemingly random places to solve an error instead of tracing backwards from the error message in front of their face.

ryandrake 8y ago

Related: Read the official documentation. I can’t count how many times junior folks have asked me things like, does FooBarFactory constructor take an array of ints or floats? Well, what does their documentation say? Sometimes the official documentation is crap and that’s a reasonable question, but usually the answers can be found in TFM.

ggregoire 8y ago
I noticed a similar trend in JS dev: asking/looking for (video) tutorials instead of reading the official doc. Even when the doc is good and quick too read (React, Redux, Vue, etc).
- charmides 8y ago
  Related to that, usually I am a little faster finding answers to syntax questions on SO than in the documentation, even when the documentation is good. So I'm glad that people have been asking those basic questions on SO.
- baggsie 8y ago
  I tend to grok things a great
- AYBABTME 8y ago
  Yeah, it's a bit weird why people have this expectation to reach for tutorials by random person X instead of looking for the official docs. I can't count the number of time someone asked me which tutorials to read to learn Go, but hadn't even considered reading the docs.

axpence 8y ago

100% agree. Likewise, I think adopting a "how can I create a stack trace/error message" mindset is incredibly important. Can you add a breakpoint to a certain piece of code? Could you add a try/catch statement somewhere to catch the error? Far too often good engineers do not have an "active" mindset in hunting for stack traces/error messages, instead, they wait for them to fall like manna from heaven.

Agathos 8y ago
Raise your hand if you've ever created an insert/update database trigger that explodes when that it sees that one bad value you've been investigating, just so you'll have a traceback that points to the offending code. (Hopefully only in your development environment.)

JepZ 8y ago

In general, I agree that juniors tend to skip useful information, but it depends a bit on the technology you are working with. PHP, for example, was known to report the error for the line after the one you forgot the semicolon at or at the line after the last line of the file when a parenthesis was missing somewhere. While there is a reason why it did so, those are error messages which are quite hard to understand the first few times they occur to you. Nevertheless, those lousy error message should be exceptions nowadays, and if you are using decent technologies, the chances are much higher, that you just didn't read the error message not careful enough to understand the problem.

C4stor 8y ago
My comment is a bit extreme in its tone indeed ! It's just that it's the advice I've given the most by orders of magnitudes, and I'm still amazed (and a bit weary) it's worth even mentioning. And to make it stick, I've removed any nuance of it...

rand_r 8y ago

I think a lot of the time people are perfectly capable of figuring out the issue on their own, however they ask for help for social reasons. Getting another person involved in the problem is way more fun, and creates a bond between both people.

dlivingston 8y ago
I've observed this a few times, too.
klohto 8y ago
When you’re messaging me 20 times a day about simple exceptions like “X gem is not installed” (Ruby) and asking me what to do, then it has an opposite offect of creating a bond
- petepete 8y ago
  For non black and white problems it makes more sense though. Discussing the best approach for something complex, for example. Timing is important though, you don't want to intrude, interrupt or distract.

andy_wrote 8y ago

I really like your last point "whatever the computer is telling is true from the computer point of view". In a surprising number of coding interviews that I've conducted, I've seen a candidate write an incorrect solution that generates an exception and then attempt to figure out the error almost on first principles, rather than actually reading the exception carefully and thinking about what coding errors could have caused it to happen. The exception message is a _huge_ hint! It's a red flag to see someone try to debug without paying attention to it. Conversely it's very positive to see someone encounter one and then think carefully about it. Writing an incorrect solution but then testing it out and showing the ability to debug and fix it systematically and expediently is no worse than getting it right on the first try, in my book.

fhood 8y ago
It isn't just a huge hint, most of the time it tells you exactly what the damn issue is. This discussion is blowing my mind. I am honestly speechless. IT GIVES YOU THE LINE NUMBER AND THE FUNCTION CALL AND THE REASON! Why would you ever even attempt to debug without parsing it?
- dsr_ 8y ago
  And in the opposite direction: remember when you are writing error messages to include all the relevant details, and never ever write "this shouldn't happen" or "document later".
  - fhood 8y ago
    What about, log_panic("If we have somehow managed to hit this code path, this project if FUBAR. I would recommend giving up and starting over.")
    - m_samuel_l 8y ago
      That's annoying but fine as long as it's unique and you can grep it in the codebase.

PurpleBoxDragon 8y ago

Eventually you'll learn what errors can be ignored, what are useless information, and which ones are sending you down a path that will waste time. But only start skipping and skimming once you've learned what to look for, and always be prepared to toss out the old knowledge when working on a new system. Also, when you have far too many logs, reading in reverse chronological order works most of the time, but not all the time. Generally the last error you are looking at is the error you want to find and fix, but always consider that sometimes an earlier error that seems unrelated can be the reason a later error is even possible.

ljm 8y ago

This is a good insight. Many a time I've offered a fix to a bug and the response was "how did you figure that out?" My answer was that I looked at the error message and then, if it was available, scanned the backtrace to figure out which files/method calls were involved. Otherwise (particularly with JS), I set up some breakpoints in the browser to help visualise things better. I've come across plenty of senior developers who ignore what the machine says. The thing is, most bugs aren't solved through intuition, so approaching the problem as if your gut feeling is completely accurate is going to turn a 10 minute debugging session into something that could last a full day. As, in my experience, it once did.

Aeolun 8y ago

Also great advice for a senior. Great advice for anyone really.

imgabe 8y ago

Ok, I'm strictly a hobby developer so I don't really have co-workers to go ask for help. Do people really not read error messages? That boggles my mind. How would you ever figure out what went wrong? I mean, how could anyone ever learn to program well enough to get a job as a professional programmer without knowing to do that?

dx87 8y ago
A lot of programming jobs just need someone who can follow directions, not someone very skilled. It's the digital equivalent putting together IKEA furniture instead of being the person doing all the design work to ensure things fit together and the directions are simple to follow. The most common way I've seen people try to figure out what went wrong is sprinkling stuff like "console.log("Here1"), console.log("Here2") throughout the code until they figure out which "Here" statement wasn't printed, then they start making random changes to values until the error reflects the changes that they made, then they check stackoverflow, if there aren't any results, they'll paste the error message with no context, having learned nothing in the process. It's pretty common in any field where you can get by knowing "what" to do, vs "why" to do something. I've seen the same thing teaching Linux classes where someone throws up their hands and gives up because they tried to cat a file and it said "error: no such file or directory", but they just saw "error", and decided it was too difficult.
jetti 8y ago
There are certain people that just don't have developed critical thinking skills and will shut down the minute something goes different than expected. I have dealt with a few of those types of people in my career and it is incredibly frustrating. The best thing you can do for them is not to help them in the way they want, by giving them the answer, but by making them do some of the grunt work on their own before they even come to you. I ask a lot of questions about what they are seeing and if they can't answer them then I make them go back until they can. Simple things like "what have you searched for regarding this", "what does the error message say" in order to get them in the habit of actually starting to look into their own issues.
PeterisP 8y ago
The obvious answer is they don't figure out what went wrong, they tweak the program until the problem goes away for a while.

fisherjeff 8y ago

This is excellent advice, and I would suggest reading warnings (e.g., compiler warnings) as well – even if they don't indicate a problem, understanding why a warning is thrown is often a very worthwhile exercise.

beardbound 8y ago

I work in QA and I wish more developers thought this way. Also run your code before hand off. Please. If I had a nickel for every time I got a user story or bug to validate and it immediately crashes then I would have a bunch of nickels. Which wouldn't be super helpful, but still. Please at least run your code, or ideally you should have CI/CD with unit tests, but we all know that isn't always the case especially in legacy Enterprise software.

debaserab2 8y ago
It's easy to make the assumption that developers haven't ran the code at all, but I find in reality that's rarely the case. In my experience it almost always has something to do with an unexpected environment variant. It's very easy as a developer to get so comfortable with the "happy path" of navigating code that you forget to look outside of the happy path when devising your test cases. It takes time to learn to identify the test cases you're not regularly exposing yourself, and these test cases are often ones not described in a requirements or specs doc.
- rcollyer 8y ago
  As a QA dev, myself, I run across this occasionally. For a recent bug, the dev couldn't reproduce it, yet I could consistently. The difference: the width the window we were using; he was using the default, I was not. Most of the bugs I run into are not config dependent, so it is always surprising when one is.
- egfx 8y ago
  This! I spent the first half of my career in QA. This second half in dev. Coming from QA I'm very meticulous about everything and yet as soon as it leaves my hands something comes up. This is why I'm a big proponent of QA. I had a chat with someone who was pretty much dismissing QA because they had the mindset of I'll just test it or my cofounder will help. It's terribly surprising what goes down outside the confines.
phaedrus 8y ago
As a developer this bugs me too. I once was team lead on a team which had two developers (bad hires) who seemed to believe that it was only their job to write the code, someone else's job to run it and test it. I started putting "and test the code" in the tasks; a team member successfully lobbied our manager that that was another task. So now I had to write 2x as many tasks, and the predictable result happened: the developers who didn't test their own code grabbed all the "write the feature" tasks and banged them out rapidly (easy to do when you don't make sure it works!) The more experienced developers were left to pick up the "and test what you wrote" tasks, which really amounted to rewriting the bad code. Then management said, "Why are you (senior developers) wasting so much time testing code? It generally seems to work and we can always fix it later." There was just no way to win. I'm glad I don't work in that environment anymore.

byron_fast 8y ago

Don't think, just set the halt. https://ronjeffries.com/xprog/articles/practices/pracjustsetthehalt/ https://ronjeffries.com/xprog/articles/practices/pracjustset...

btschaegg 8y ago

An addendum to that: Design your error messages. When dealing with exceptions, catch/wrap the exception (e.g. using InnerException in .NET) and add important information if necessary. You'll be glad you did six months down the line, when the exception actually pops up and you instantly know how to reproduce the bug (perhaps because you know the id of the business object involved). Edit: Also, use understandable text for error messages. Don't go around talking about threads/sockets etc. unless they happen on that abstraction level. The user should see business-level errors, so they know what happened in the business domain and why ("we don't know why, this shouldn't have happened" is a reasonable answer there, too). Edit 2: I just thought of Git's "plumbing vs porcelain" metaphor. Abusing it slightly: It's much more pleasant to be notified of an error by a red light instead of standing ankle-deep in sewage. I guess that metaphor breaks down a bit, since toilets more often have the latter than the first :)