[HN Gopher] Errors are not failures
___________________________________________________________________
Errors are not failures
Author : csmeyer
Score : 39 points
Date : 2023-02-17 18:38 UTC (2 days ago)
(HTM) web link (blog.charliemeyer.co)
(TXT) w3m dump (blog.charliemeyer.co)
| bin_bash wrote:
| 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.
| lloydatkinson wrote:
| 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 wrote:
| 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".
| atoav wrote:
| 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.
| xorcist wrote:
| 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.
| jeffreportmill1 wrote:
| 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 wrote:
| "Programming as theory building" by Peter Naur touches that.
|
| https://news.ycombinator.com/item?id=10833278
| nivertech wrote:
| 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.
| clnq wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| tbrownaw wrote:
| There have been times that I _deliberately_ didn 't "finish"
| some code, just because making it work properly for the
| remaining edge cases would cost more time than it would save.
|
| https://xkcd.com/1205/
| lll-o-lll wrote:
| 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 wrote:
| 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.
| eyelidlessness wrote:
| 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.
| hakunin wrote:
| 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.
| goalieca wrote:
| 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 wrote:
| 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.
| scns wrote:
| Each "mistake" you still have to make, is a treasure you have to
| dig out.
___________________________________________________________________
(page generated 2023-02-19 23:03 UTC)