4 ms·

Errors are not failures

48 points by csmeyer 4y ago

jeffreportmill1 4y ago
I totally agree with you. Sometimes I think programming has ruined doing things in the real world - I’m spoiled by the idea that I can slap things together, then iterate to a refined result. But if you do that with anything else, like cooking or home improvement/maintenance, you just end up with a mess.
- hcarvalhoalves 4y ago
  “Programming as theory building” by Peter Naur touches that. https://news.ycombinator.com/item?id=10833278 https://news.ycombinator.com/item?id=10833278
lll-o-lll 4y ago
Not sure I completely agree with this. It’s true that errors are feedback, and iterating from them makes progress. I just think it’s easy to get stuck in an inefficient loop. You’re making progress, no need to think harder. When I first started programming for actual money (an embarrassing number of years ago now) I remember the old guy mentoring me wouldn’t let me use a debugger. “You have to think through the code, the debugger is the last resort”. I didn’t agree, it just looked like masochism and bravado from someone who hadn’t had good tools so I should suffer too. Now that I’m the old guy, I recognise the wisdom. Stepping back, thinking through the problem, and you can write all that code without the inefficiency “run” “error” “modify”. Or maybe that’s just how us old guys think.
- onei 4y ago
  I never /really/ learned how to use a debugger. I know what one is and know enough to flounder around in one, but I haven't reached for one in a long time. These days, I work on buzzwords like kubernetes, microservices and Go and I likely couldn't use a debugger for customer issues even if I wanted to. Instead, I rely on a mix of intuition, logs and sometimes blind luck. I wonder if I've accidentally ended up in a domain that isn't that difficult. Or perhaps my luck will run out and I'm going to hit a debugging brick wall some day in the future.
  - wellanyway 4y ago
    You should see tye faces of people when they observe mee looking at strace or something.
- goalieca 4y ago
  The lessons here are that understanding the code will have to happen anyways and that it is actually easier to tackle one problem (understanding the logic) rather than two problems (understanding the logic through the mechanics of how it is implemented at the machine level). Sometimes you have to slow down to go faster.
- olodus 4y ago
  I usually think of it as a very scientific inspired process. Information gathering - Hypothesis forming - testing - evaluation. Easy problems / bugs require next to no hypothesis. You just see the error, backtrace or whatever and can go fix it. But harder bugs and system bugs usually require information gathering and analysis of that information to figure out and form a good hypothesis. To do that, just like your mentor said, you need good knowledge of the code and good understanding of what the information is telling you and what that can suggest or rule out.
- hakunin 4y ago
  I've had way more success than I probably should have using something I now call "empathy driven debugging". I almost never use a debugger, instead I try to imagine I'm the person who wrote this program, and imagine where I might introduce this issue, and almost every freaking time I find the craziest stuff very quickly.
- eyelidlessness 4y ago
  I also find myself relying less on debuggers over time, but I think it’s for very different reasons. Namely, I get more of the kind of feedback I’d want either before even running the code (type checker, linter, etc all providing instant feedback in editor); or from improved code navigation tooling (type checker/editor again); or from years of honing my test writing instincts (if it’s worth debugging, it’s likely also worth testing, so you don’t have to debug it again). But this is all very different from “just” thinking through the code. If anything, my cognitive capacity has declined significantly with age. I depend heavily on tools to shorten the paths I have to think through in the first place. And tests (if you’re doing TDD anyway) are just a more efficient “run, error, modify” after all.
- wellanyway 4y ago
  Most reliable finding of my career is that when I meet at big problem, the best thing is to go "touch grass" as kids say these days. I will get my solution while climbing or standing in the shower. Whacking at the keyboard for 12 hours straight and ingesting ungodly amounts of stimulants will not help. Having said that, I am quite keen to not learn from my experoence and I keep doing a thing I know doesnt work.
scns 4y ago
Each "mistake" you still have to make, is a treasure you have to dig out.
bin_bash 4y ago
I've seen this behavior with new coders too. They see an error and immediately get paralyzed and reach out for help without actually reading it to see what it says. I think non-technical people see an error message and don't take the time to read it, they just assume that the text is just nonsense. That's fair, of course, and reading error messages can be very hard sometimes even for the best of us. Still, I think there is a psychological hurdle to understand errors as a process, not as a roadblock.
- atoav 4y ago
  I always tend to present it to beginners as a way of the computer to tell you what is going on. Programming is (among other things) the art of knowing how to speak to a computer and gow to interpret the things it says. That means everything that damn thing says gives you hints of how it "sees the world" and how you therefore need to describe things to it so it can execute them for you.
- lloydatkinson 4y ago
  Or the worst variant, who seem numerous at my current job, that get paralysed and then simply give up and either turn off warnings, resort to type hacks (eg if they are using TS they will just just the any keyword), or radically change their design to far below any reasonable quality. Then they act surprised when someone objects to any of this in pull request reviews and even more surprised when asked to do it properly and finally even more surprised when asked why they didn’t reach out for help. They always seem genuinely like they’ve never heard of the idea of help before despite being repeatedly asked to ask for help when they aren’t sure. Really hard to say what this is but this level of hand holding required feels like a failure in a part of the interview process.
  - Zababa 4y ago
    I don't know about other people, but for me, it gets tiring to ask for help all the time, and I'm not used to working with senior people. Programming in college was with groups of people as clueless or even more clueless than me, so asking for help was useless. And most of my programming I did on my own. I'm also not very good with people in general, or rather, after I spend "too much" time with someone I need some time alone to recharge my social batteries. It's also hard to know exactly what "not being sure" is. Does that mean 15 minutes without progress? An hour? Half a day? What if I'm still making progress, but slower than usual? Seniors love to say "ask for help if you're not sure" but I've never heard anyone properly defining what "not sure" is supposed to be. When I ask for clarification, some of the time people look at me like I'm an alien. I understand that managing people is hard, but I also find it hard to be managed when expectations aren't clear and are mostly a reflection of "I wish things were better".
xorcist 4y ago
Strongly disagree. Errors should be things that someone needs to look at. It's not necessarily a problem, but could potentially be. Otherwise you end up with the situation described in the article, where a newcomer to the system has to slog through a lot of noise in order to understand what is going on. But even experienced people will have trouble seeing the real errors in a sea of red. A few times I have insisted on escalating every error in order to improve a noisy program. A client that breaks connection with us isn't an error, that's a notice. An upstream database that breaks connection with us so we can't process a query, that's an error. It's not fun but it gets better.
clnq 4y ago
I disagree. Errors are failures. Not just failures in code execution, but also, objectively, shortcomings of the programmer's skill. It's very difficult to deny this because there is usually a lot of evidence. However, there is something to be said about accepting one's mistakes and not wasting time dwelling on them; and instead looking at the bigger picture, or at least at something more constructive. Life in general is a lot better once we learn to do that. For the new software engineers that are too frustrated by their constant mistakes, I want to say a few things: 1. You cannot become an experienced software engineer without getting the experience. 2. You cannot become skilled in a programming language or any tech without spending the time to become skilled at it. 3. You were not born entitled to be a good software engineer. As a baby, you were objectively awful in the discipline. As you have progressed to your current level of expertise in software, so will you continue to progress. 4. It is best to not overthink software engineering and just try to do it well. 5. You are the only judge of your failures and successes in life. No one else in the world decides how you feel about them. It is your prerogative to forgive your own mistakes - big and small (like a coding error) - if you so wish. 6. All new software engineers make many mistakes. 7. Likewise, all experts in every field regularly make mistakes. Just the kind of mistakes are different. But it is the human condition to make mistakes. 8. You will probably get to where you're going in the end if you persevere.
- wyldfire 4y ago
  > Errors are failures. Not just failures in code execution, but also, objectively, shortcomings of the programmer's skill. "file not found" and "permission denied" illustrate shortcomings? how else could you get this information if not from an error message?
  - clnq 4y ago
    I was talking more about the errors and crashes one sees while developing software. What you bring up is more from the software user perspective. If a software engineer sees their software crash because files or permissions are missing, I think that is definitely an opportunity to improve their skills and handle such cases in their code. And I want to be clear about this - I do not blame, nor judge, nor is it my place or predisposition to judge people for errors in their code. But I think for those who judge themselves as many software engineers do, it is important to make peace with making mistakes.
nivertech 4y ago
This post takes a very narrowed point of view on errors, i.e. mostly errors addressed to developers: compiler errors, runtime errors/exceptions/crashes, etc. There are many different kinds of errors, but they can be roughly divided into two categories: business errors and technical errors. Business errors are not really an errors, but rather alternative business outcomes. Paraphrasing Kellyanne Conway: business errors are alternative results;) Something like Saga pattern or ACID transactions can be used to handle this kind of errors. Technical errors are also a huge category, the most important properties are whether they can be reported to the end-user, or they make sense to developers only. Also are they retriable or not. Lastly, some programming languages/runtimes/VMs reporting lots of ignorable errors, e.g. look at the log of any JVM application, you will see lots of exceptions, same in the browser's JS console. Even in Erlang/Elixir logs you will see supervisor errors, etc. IMO it make sense to expect clean logs in case of normally functioning application, but that's not the case for most development environments today.

48 points by csmeyer 4y ago

I totally agree with you. Sometimes I think programming has ruined doing things in the real world - I’m spoiled by the idea that I can slap things together, then iterate to a refined result. But if you do that with anything else, like cooking or home improvement/maintenance, you just end up with a mess.

hcarvalhoalves 4y ago
“Programming as theory building” by Peter Naur touches that. https://news.ycombinator.com/item?id=10833278 https://news.ycombinator.com/item?id=10833278

lll-o-lll 4y ago

Not sure I completely agree with this. It’s true that errors are feedback, and iterating from them makes progress. I just think it’s easy to get stuck in an inefficient loop. You’re making progress, no need to think harder. When I first started programming for actual money (an embarrassing number of years ago now) I remember the old guy mentoring me wouldn’t let me use a debugger. “You have to think through the code, the debugger is the last resort”. I didn’t agree, it just looked like masochism and bravado from someone who hadn’t had good tools so I should suffer too. Now that I’m the old guy, I recognise the wisdom. Stepping back, thinking through the problem, and you can write all that code without the inefficiency “run” “error” “modify”. Or maybe that’s just how us old guys think.

onei 4y ago
I never /really/ learned how to use a debugger. I know what one is and know enough to flounder around in one, but I haven't reached for one in a long time. These days, I work on buzzwords like kubernetes, microservices and Go and I likely couldn't use a debugger for customer issues even if I wanted to. Instead, I rely on a mix of intuition, logs and sometimes blind luck. I wonder if I've accidentally ended up in a domain that isn't that difficult. Or perhaps my luck will run out and I'm going to hit a debugging brick wall some day in the future.
- wellanyway 4y ago
  You should see tye faces of people when they observe mee looking at strace or something.
goalieca 4y ago
The lessons here are that understanding the code will have to happen anyways and that it is actually easier to tackle one problem (understanding the logic) rather than two problems (understanding the logic through the mechanics of how it is implemented at the machine level). Sometimes you have to slow down to go faster.
olodus 4y ago
I usually think of it as a very scientific inspired process. Information gathering - Hypothesis forming - testing - evaluation. Easy problems / bugs require next to no hypothesis. You just see the error, backtrace or whatever and can go fix it. But harder bugs and system bugs usually require information gathering and analysis of that information to figure out and form a good hypothesis. To do that, just like your mentor said, you need good knowledge of the code and good understanding of what the information is telling you and what that can suggest or rule out.
hakunin 4y ago
I've had way more success than I probably should have using something I now call "empathy driven debugging". I almost never use a debugger, instead I try to imagine I'm the person who wrote this program, and imagine where I might introduce this issue, and almost every freaking time I find the craziest stuff very quickly.
eyelidlessness 4y ago
I also find myself relying less on debuggers over time, but I think it’s for very different reasons. Namely, I get more of the kind of feedback I’d want either before even running the code (type checker, linter, etc all providing instant feedback in editor); or from improved code navigation tooling (type checker/editor again); or from years of honing my test writing instincts (if it’s worth debugging, it’s likely also worth testing, so you don’t have to debug it again). But this is all very different from “just” thinking through the code. If anything, my cognitive capacity has declined significantly with age. I depend heavily on tools to shorten the paths I have to think through in the first place. And tests (if you’re doing TDD anyway) are just a more efficient “run, error, modify” after all.
wellanyway 4y ago
Most reliable finding of my career is that when I meet at big problem, the best thing is to go "touch grass" as kids say these days. I will get my solution while climbing or standing in the shower. Whacking at the keyboard for 12 hours straight and ingesting ungodly amounts of stimulants will not help. Having said that, I am quite keen to not learn from my experoence and I keep doing a thing I know doesnt work.

scns 4y ago

Each "mistake" you still have to make, is a treasure you have to dig out.

bin_bash 4y ago

I've seen this behavior with new coders too. They see an error and immediately get paralyzed and reach out for help without actually reading it to see what it says. I think non-technical people see an error message and don't take the time to read it, they just assume that the text is just nonsense. That's fair, of course, and reading error messages can be very hard sometimes even for the best of us. Still, I think there is a psychological hurdle to understand errors as a process, not as a roadblock.

atoav 4y ago
I always tend to present it to beginners as a way of the computer to tell you what is going on. Programming is (among other things) the art of knowing how to speak to a computer and gow to interpret the things it says. That means everything that damn thing says gives you hints of how it "sees the world" and how you therefore need to describe things to it so it can execute them for you.
lloydatkinson 4y ago
Or the worst variant, who seem numerous at my current job, that get paralysed and then simply give up and either turn off warnings, resort to type hacks (eg if they are using TS they will just just the any keyword), or radically change their design to far below any reasonable quality. Then they act surprised when someone objects to any of this in pull request reviews and even more surprised when asked to do it properly and finally even more surprised when asked why they didn’t reach out for help. They always seem genuinely like they’ve never heard of the idea of help before despite being repeatedly asked to ask for help when they aren’t sure. Really hard to say what this is but this level of hand holding required feels like a failure in a part of the interview process.
- Zababa 4y ago
  I don't know about other people, but for me, it gets tiring to ask for help all the time, and I'm not used to working with senior people. Programming in college was with groups of people as clueless or even more clueless than me, so asking for help was useless. And most of my programming I did on my own. I'm also not very good with people in general, or rather, after I spend "too much" time with someone I need some time alone to recharge my social batteries. It's also hard to know exactly what "not being sure" is. Does that mean 15 minutes without progress? An hour? Half a day? What if I'm still making progress, but slower than usual? Seniors love to say "ask for help if you're not sure" but I've never heard anyone properly defining what "not sure" is supposed to be. When I ask for clarification, some of the time people look at me like I'm an alien. I understand that managing people is hard, but I also find it hard to be managed when expectations aren't clear and are mostly a reflection of "I wish things were better".

xorcist 4y ago

Strongly disagree. Errors should be things that someone needs to look at. It's not necessarily a problem, but could potentially be. Otherwise you end up with the situation described in the article, where a newcomer to the system has to slog through a lot of noise in order to understand what is going on. But even experienced people will have trouble seeing the real errors in a sea of red. A few times I have insisted on escalating every error in order to improve a noisy program. A client that breaks connection with us isn't an error, that's a notice. An upstream database that breaks connection with us so we can't process a query, that's an error. It's not fun but it gets better.

clnq 4y ago

I disagree. Errors are failures. Not just failures in code execution, but also, objectively, shortcomings of the programmer's skill. It's very difficult to deny this because there is usually a lot of evidence. However, there is something to be said about accepting one's mistakes and not wasting time dwelling on them; and instead looking at the bigger picture, or at least at something more constructive. Life in general is a lot better once we learn to do that. For the new software engineers that are too frustrated by their constant mistakes, I want to say a few things: 1. You cannot become an experienced software engineer without getting the experience. 2. You cannot become skilled in a programming language or any tech without spending the time to become skilled at it. 3. You were not born entitled to be a good software engineer. As a baby, you were objectively awful in the discipline. As you have progressed to your current level of expertise in software, so will you continue to progress. 4. It is best to not overthink software engineering and just try to do it well. 5. You are the only judge of your failures and successes in life. No one else in the world decides how you feel about them. It is your prerogative to forgive your own mistakes - big and small (like a coding error) - if you so wish. 6. All new software engineers make many mistakes. 7. Likewise, all experts in every field regularly make mistakes. Just the kind of mistakes are different. But it is the human condition to make mistakes. 8. You will probably get to where you're going in the end if you persevere.

wyldfire 4y ago
> Errors are failures. Not just failures in code execution, but also, objectively, shortcomings of the programmer's skill. "file not found" and "permission denied" illustrate shortcomings? how else could you get this information if not from an error message?
- clnq 4y ago
  I was talking more about the errors and crashes one sees while developing software. What you bring up is more from the software user perspective. If a software engineer sees their software crash because files or permissions are missing, I think that is definitely an opportunity to improve their skills and handle such cases in their code. And I want to be clear about this - I do not blame, nor judge, nor is it my place or predisposition to judge people for errors in their code. But I think for those who judge themselves as many software engineers do, it is important to make peace with making mistakes.

nivertech 4y ago

This post takes a very narrowed point of view on errors, i.e. mostly errors addressed to developers: compiler errors, runtime errors/exceptions/crashes, etc. There are many different kinds of errors, but they can be roughly divided into two categories: business errors and technical errors. Business errors are not really an errors, but rather alternative business outcomes. Paraphrasing Kellyanne Conway: business errors are alternative results;) Something like Saga pattern or ACID transactions can be used to handle this kind of errors. Technical errors are also a huge category, the most important properties are whether they can be reported to the end-user, or they make sense to developers only. Also are they retriable or not. Lastly, some programming languages/runtimes/VMs reporting lots of ignorable errors, e.g. look at the log of any JVM application, you will see lots of exceptions, same in the browser's JS console. Even in Erlang/Elixir logs you will see supervisor errors, etc. IMO it make sense to expect clean logs in case of normally functioning application, but that's not the case for most development environments today.