10 ms·

I would, if i had any evidence at all that they would be read and acted on. I’m convinced even seemingly competent people are just rendered contextually blind b

I would, if i had any evidence at all that they would be read and acted on. I’m convinced even seemingly competent people are just rendered contextually blind by the appearance of any error at all. In the past month, i’ve had about a dozen interactions like this: developer: your service crashed, here’s a screenshot of the last 5 lines of the crash me: do you see where the final text you just pasted is “RuntimeError: Did not find ENVVAR, ensure this is set to the proper value (see <internal wiki link>) and then restart this service” developer: yeah? me: well, did you do that thing? developer: what thing? me: <headdesk> and this at work, where the developer in question is intimately acquainted with the context and purpose of the project.

residualmind 4y ago
Actually reading (and understanding, acting upon) error messages seems to be part of the learning process of every developer. And while more senior devs usually do read error messages, even they sometimes, rather than reading it will jump to behavior like "trying again a different way", before looking closely what went wrong.
- hinkley 4y ago
  Developers often seemed shocked that people can’t find the important error in a wall of text. A particular peeve is when the same error is reported three ways and the real error is sandwiched between others or scrolled off the screen due to spammy behavior.
ajnin 4y ago
How many interactions didn't you have, because the developer read the error message, read the Wiki, and ultimately solved the issue themselves ?
- deleted 4y ago
  [deleted]
zagrebian 4y ago
This just means that the error message needs to be more clear. For example, after the error itself, it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to <wiki link>. Set ENVVAR to a proper value and restart the service.” Notice the direct language. It reads like an order. The less direct the message, the higher the chances that the user will not act upon it.
- dvtrn 4y ago
  I’m not seeing how what the message already is any less direct or clear than what you’re saying it should be? It straight up tells you it can’t find the var and what to do about it. Can you help me understand what isn’t clear about the message as is, or maybe point out the ambiguity to someone who just isn’t seeing it? I want to write better error messages but I share the frustration of the above poster. The message tells you specifically what to do, but you’re coming back saying it’s not clear.
  - lupire 4y ago
    Some people don't read anything that isn't an all-caps command. They have learned helplessness from seeing too much useless error text in the past.
  - j-bos 4y ago
    I think the original error is quite clear, under normal circumstances. Not OP but I've noticed that people often get brain fog when something goes wrong and are often need BIG, SHORT, WORDS to shake out of it. Or really anything that can shake them out of the 'idunno' state of mind. But maybe if something like that became standard ut would no longet be a context switcher..
    - ckozlowski 4y ago
      I think you're spot on, and I made a similar comment above. It's easy to say "they can figure it out". Sure, in a restful state. But the people we're asking to take action already have a lot on their plate. Using plain, conversational language whenever possible with exceedingly clear steps means less mental exertion on the receiver. And since we need their help, anything we can do to make it easier on their end helps us.
Joker_vD 4y ago
Well, imagine the error was simply "RuntimeError: Environment variable not set" instead, then how much of your time would have been wasted by those dozen interactions?
grandinj 4y ago
Some developers are just lazy, and will likely need some kind of negative feedback to force them to confront their own laziness. Which can be tricky, because the degree of negative feedback that is appropriate to the person in question can range from "Polite one-on-one suggestion that you read the error message more than once before calling me" to "Full on yelling at the person in the middle of an open-plan office". Thankfully, type II is rare, but they do occur.
- lupire 4y ago
  Send a link to wiki. Last line of page is "if you have questions, reach out and include the keyword $THIS_PAGE_KEY in your message."
- bartread 4y ago
  > Some developers are just lazy I'm really lazy: if I were on the receiving end of emails with error messages that included instructions about how to fix said error I'd automate Freshdesk (or whatever ticketing system I was using) to respond with instructions specific to that error message, in the first instance, along with a note to get in touch again if that didn't solve the problem. I'd also set the ticket to autoresolve after a set period of time.
jimmytidey 4y ago
This is a context where people are used to seeing errors that they don't know what to do with. If a web app pops a well written error it is much more likely to be acted on than an unmotivated dev seeing a some (probably badly formatted) text. Every time I see an error in terminal with a link to documentation I'm delighted. And surprised.
- nerdponx 4y ago
  So? That's no excuse for a developer to disregard the content of an error message in their own application.
  - lijogdfljk 4y ago
    It kinda is. Kinda like when documentation is so repeatedly outdated and incorrect, that when you need new information you just skip documentation entirely. Are you wrong for skipping documentation? Yea, maybe. Is it entirely expected? Yea. Based on the parent comment, at least.
  - monknomo 4y ago
    And yet developers do disregard the content of error messages. Try to figure out why they disregard it. I doubt the answer is "because they're stupid". The answer probably also isn't "because they just aren't trying". What could it be? Why do people read things and react in similar ways, even if they have different jobs? If only there was some field of study that could answer these mysteries.
- Kalium 4y ago
  Once upon a time, I worked at a financial startup (the company is irrelevant). I created a little harness around a static analysis tool. It would fail builds when a library had an outstanding vulnerability scored as HIGH or SEVERE with a patch available. The harness put a friendly error message around it. It ran roughly as follows: > Hi! If you're reading this message, it's likely because this tool failed your build. To understand why and fix it, please click this link <link_to_internal_doc>. Below is a table that lists the packages you need to update and the version you need to update them to. The doc had at the very top in big flashing red text with siren anigifs a link to the portion that explained that they needed to update their libraries with very clear copy-paste-into-Dockerfile actionable guidance. The page also explained the broader context, such as the point of the tool and why we were doing this despite having a firewall and so on. This is where you might be delighted and surprised. What was perhaps less delightful and surprising were the consequences for me. About 4-6 times a week, I would then have a Slack conversation akin to this: Dev: Why did you break my build!?! Me: Can I see the error message? Dev: <pastes message above> Me: Thanks! Looking at the message, is there something unclear about the documentation? Does it not work? <ten minutes pass> Dev: Nope! Docs are great! At this point the conversation would end.
chillfox 4y ago
Don't send people somewhere else to learn how to fix the error. The more steps and indirection you add the fewer people will bother doing it themselves, especially if they can bump it to the developer. Make it easy for people to fix their own problems by being explicit, direct and complete. List all the steps and use formatting to make it visually easier to consume. So your error message while a far cry from the worst I have seen is also pretty far from the good ones I have seen.
- starkd 4y ago
  I think his point was the developer tends not to even investigate the ENVVAR at issue or visit the link. If the developer does investigate the link and still has an issue, than you have a point.
  - chillfox 4y ago
    Pretty sure his problem was he got contacted about an issue he considers uninteresting, and his preferred solution is the user stops behaving like a human. Reaching for the easiest way to solve a problem first is a very human thing to do, and in this case he was easier to contact than opening up a browser and reading an article that presumably is written in the same kind of language as the error message.
    - dvtrn 4y ago
      I’m left wonder at what point does the “give a man a fish/teach a man how to fish” method of pedagogy apply in terms of ‘acting like a human’ in this context? Asking as someone who otherwise generally agrees that there are some truly poorly written errors and exceptions out there, but has also been on the admittedly frustrating end of the constant requests for help deciphering error messages that were very plainly stating what the problem is for someone who didn’t even try looking for the fishing rod.
      - chillfox 4y ago
        Sure, clearly there are people who will never try, or learn, but in general as an industry I feel like the wast majority of errors are very very far from good. Few error messages are written well, has good formatting and are self contained (can be used to fix the issue without having to seek further information elsewhere). Sometimes you see errors that contain one of those elements, but rarely all of them. There has been an effort the last few years improving compiler errors for some languages, but those same improvements have not reached applications.
lupire 4y ago
Use the error messages you wrote! Send them the link they sent you, and move on.
rjmill 4y ago
> evidence at all that they would be read I just had an idea: Put tracking info in the error URL. If your company has an internal URL shortener, that could do the trick. More practically, I feel like it helps to put an empty line before the call to action. For many people, a traceback is just noise. The empty line helps split the useful info out from the traceback. Or if it's a script/CLI (and you know the error reason) don't even show a traceback. Just print the error message to stderr, exit non-zero, and be done with it.
JTbane 4y ago
>>>“RuntimeError: Did not find ENVVAR, ensure this is set to the proper value (see <internal wiki link>) and then restart this service” I'm laughing as you could not make it clearer if you tried. PEBKAC
nkrisc 4y ago
The goal of writing better error messages isn't to help the people who never read error messages, it's to help the people who do and who you never have to hear from.
- marklubi 4y ago
  The trick that I've found is that each error message needs to be unique... not just the stack trace, but the actual wording of the message leading up to that. Get a screenshot or the exact verbatim of it, and you can identify exactly where in the code it originated. User reports are unreliable, but when I can pinpoint where the message originated from, it massively cuts down on the troubleshooting time.
  - legulere 4y ago
    In RFC 7807 all errors get an unique URI. Message texts might change or be translated into a language you don’t understand.
    - BerislavLopac 4y ago
      To be precise, each error type gets a unique URI. A good way to take advantage of that is to have a central database of all error types, but not many companies bother to do that.
      - mi_lk 4y ago
        > have a central database of all error types do you have any example?
        zem 4y ago
        here's ours for pytype (a python type checker): https://google.github.io/pytype/errors.html https://google.github.io/pytype/errors.html
    - shadowgovt 4y ago
coldacid 4y ago
The help desk guys are on the other side of a cubicle wall from my workstation, and almost every call I overhear about someone getting errors just convinces me further and further that people don't only not pay attention to the error message, they don't pay attention to the people they're calling to help them get through the situation either.
TillE 4y ago
I've seen this constantly over the years, people who absolutely refuse to read the simplest instructions, but instead require step-by-step hand-holding from you personally. I have no idea how these people get through life at all.
- dagw 4y ago
  I suspect that, at least subconsciously, they're to some extent doing that to punish you for writing 'bad' software that they have to struggle with. If they're going to suffer, you're going to suffer right along side them.
- 0x457 4y ago
  Hey, let's jump on a quick call, so we can go through this together and maybe update docs if they're out of date?
- nicbou 4y ago
  I have no idea either. For example when someone asks me "how do I get a German work visa" and I reply with a link to a page titled "how to get a German work visa", which is the among the first results on Google. A literal minute later, they ask me more questions that the page clearly answers. Some people can't be arsed to read a 5 minute article you hand-delivered to them, and would rather have you type it back to them. I think that some people just have zero respect for other people's time.
onion2k 4y ago
Shouldn't the app gracefully exit with a clear message, and not bail out in a way that looks like a crash? I'd guess that the person who wrote it hooked into the error handler because that was the easy thing to do rather than bother to write a nice way to exit properly. The fact that you've had this a dozen times points to a problem with the app more than the people using it to me.
0xbadcafebee 4y ago
The problem is here: "RuntimeError:". Once they saw that, they stopped reading. "Did not find ENVVAR" [..] "ensure this is set to the proper value" [..] "and then restart the service" are also obscure and will stop them from reading. Why is the user like this? Error message PTSD. Years of staring at obscure errors full of technical jargon that are not helpful to the user, has left them scared to even look at the content of the error message. They have tried to Google these things before and failed, and now they just avoid it entirely and run for help. I'm sure there's enough detail in the link you provided to help the user. But if that's the case, it will be better for the error message to simply say: A problem occurred, but don't worry! You can fix it yourself in 5 minutes! For instructions, visit https://internal-wiki-link/spaces/BLAH/AppUserRuntimeError#A013579 Even if you expect the user to be "smart enough" to fix their own problem, they are more likely to try it themselves if you make it seem easier.
- Kalium 4y ago
  I tried exactly this approach! What I got was a bunch of developers copy-pasting the error message with helpful URL at me and demanding to know what they should do. The number who followed the link and fixed the problem themselves was shockingly small. Going out on a limb, I think we're all going astray by trying to parse the error messages our fellow developers are reacting to. A great many seem to handle any unfamiliar or unexpected error message by giving up, no matter how friendly or informative or helpful it may be.
  - bonoboTP 4y ago
    They don't parse the error message as a natural language sentence talking to them. They take it as an opaque string, like a big error code. It literally passes through them without getting interpreted. They learned that the affordances of these error messages are copy pasting into some place: a google search box, or a chat box asking for help. But it has no affordance of "interpret as an English sentence" for them.
  - 0xbadcafebee 4y ago
    If that's the case, then these people may just need training. It's likely that nobody has ever sat them down and explained that they have a responsibility to investigate their own issue. Often people feel they have to rush to get something done, and that they can't take time to troubleshoot. But if their bosses explained that, actually, it's fine if your work is a little late due to troubleshooting, they might do it themselves more often. You also may need to provide back-pressure by interacting via email/ticket.
AlwaysRock 4y ago
It's a little annoying but to be fair because most error messaging is garbage, its easy to start to ignore them. How often is the error message shown, and the little fix given, actually going to solve the problem in modern web development? 10% of the time? 25% of the time? I'd be shocked if its that high.
quintussss 4y ago
Isn't this just survivor bias though? You only hear from those that fail to read and act on the error message.
bonoboTP 4y ago
It's error message blindness, similar to ad blindness. Even if you make a great banner ad with some very useful information, or the perfect and affordable product for my life I won't see it because I mentally filter out ads because they are junk most of the time. Some people develop the same with relation to error messages because most of them are not actionable, other than "stuff broke somehow, [gibberish] blabla". Even if your error message is impeccable, it's in the class of things that are noise. If you come up to me at some busy tourist location, where I'm used to lots of scammers, I won't listen to you even if you are actually a nice person and just want to have a nice chat and we would be compatible friends. Often it is a good strategy to just ask people. Documentation and comments get out of date very fast. If you are the kind of person who reads everything meticulously and googles around, reads manuals etc. you may be wasting a lot of time. Of course there is a right balance to find. Some people err too much on the side of not thinking themselves and immediately asking for handholding, but overall it's often the right thing to do. In many cases I found that trying to reason out what was going on was hopeless, because when I eventually gave up and asked someone, it turned out that the solution was unguessable, something like "ah of course, that things is out of date, do this magic incantation, then this and that, yeah we should update the docs sometime!". A lot of knowledge is locked up inside people's brains and just spreads around as "rumors" on the grapevine. Is that state of affairs ideal? No. But it's realistic and people are going to adapt by asking first, thinking second.
- BlargMcLarg 4y ago
  Asking people is mostly bad habits from a culture too ingrained into the whole 'ask first' thing, and often times it is the people trying to help that are to blame. I had this recently. Many individuals like to play hero and make sure I don't get stuck because their business is an undocumented mess. Before I even read the thing and tried, they are already trying to give me the answer. When I ask 'is this documented and if so, how would it be discovered easily' their first reaction is 'no' followed by a lengthy explanation which should be in the wiki and easy for newcomers to find. And it shows when I forget a few days later because my brain never put in the effort to get to the answer and my memory is that of a fruit fly's.
- Jiro 4y ago
outworlder 4y ago
I have managed to get a lot of notoriety in my company by just: 1. Paying attention to error messages 2. Reading documentation 3. Looking up stuff I don't fully understand(including googling error messages) That's it. Some people don't even read error messages at all. I understand non technical people doing that, but I've seen far too many engineers doing it. If anything doesn't go exactly as expected, they freeze. I have no idea how a person gets so far in their careers without reading error messages. Actually, I do, those people ask others to figure out stuff for them. That's way prevalent in enterprise settings. Sure, collaboration is good, but I've seen a lot of instances where there's a massive imbalance – you'll have 10 people pinging a single person to 'unblock' them. They could have spent a couple of minutes trying to figure out yourself. I'll move mountains to help someone that comes to me after having done some basic homework to try to fix (or at least triage) an issue. It very rare though. It's also amazing how many people will just go ahead without having read a single line of documentation of the thing they are working on. I've even had a developer dive in a Golang codebase without having _ever_ worked on the language. That would have been fine – that's how I learn new languages, just get accustomed, before doing some more formal training and exercises – except that he continued to not read the language documentation before asking a bunch of questions. Needless to say, the questions weren't good. And number 3... just rubber ducky everything. If you can't explain it, you don't get it. Go read up on the topic. Sometimes I'll find out that I don't fully understand something as I'm writing an email to others.
- vladvasiliu 4y ago
  > I'll move mountains to help someone that comes to me after having done some basic homework to try to fix (or at least triage) an issue. It very rare though. This. I actually am OK with people not figuring out even basic stuff. But please, at least try to give the impression that you've put some effort in, instead of just trying to have me do your homework while you browse facebook or whatever.
- tetha 4y ago
  > I'll move mountains to help someone that comes to me after having done some basic homework to try to fix (or at least triage) an issue. It very rare though. These are rare, but they also tend to be the really effective ones. We have a couple of teams who understand the stack, read documentation and read error messages. We generally don't hear of them for months and months, because they are too busy being productive. But when we hear of them, it's usually time to push boundaries of the infrastructure and the processes. They tried everything and nothing worked and now it's time to make it work.
deleted 4y ago
[deleted]
CityCobra 4y ago
Still, if you write proper error messages then at least you can figure out what the issue was without SSHing into the person’s computer and checking their logs.
bob1029 4y ago
This is a lesson I learned while being system owner of the primary user interface that runs on a semiconductor factory floor. No amount of confirmation/warning dialogs will actually stop someone from doing a wrong thing. Doesn't matter how scary the language is. Here's an approximate sample of one: "DANGER! Confirming this action may result in 8 figures worth of scrap!!!" Even if you are super careful and make sure your error messages are terse in all cases, you will still succumb to things like muscle memory among your users. I've caught myself mindlessly dismissing these while testing. How can I expect my users to be better than the person who developed the UI? That is unreasonable. It got to a point where we started removing these alerts/confirmations because it was training people to do the wrong thing in a few places. If you have part of a UI where all actions are immediate and final, the game theory changes. The moment a user enters into one of these spaces, they are much more cautious. If the user thinks the UI will save them, they may eventually tire of these protections and forget why they are there in the first place. I feel like this is very similar to the problem of driver assistance and partial self-driving capabilities today.
- nicbou 4y ago
  I like how GitHub asks you to type back the name of the repository you want to delete.
  - bob1029 4y ago
    For GitHub scary actions, I will not hesitate to copy and paste the expected repo name on the UI. I can do this so quickly my brain does not process the consequences in time.
pizza 4y ago
I mean it kinda makes sense. When you're coding, you're constructing something. When you're debugging, you're deconstructing something. I feel like it's natural for people to take a sec to codeswitch, bc they were likely in a state of flow w/ considerable momentum up until they saw the error
llbeansandrice 4y ago
I feel like I can't get folks to open the log file and cmd-F "ERROR" half the time.
tlogan 4y ago
This is 100% correct. In theory, all errors should: explain the input, explain the problem and explain how to solve the problem (actions). And that should help and reduce number of support calls. However, error messages and actions how to solve the error are read by maybe 1% of users. The only way to improve your UI is to prevent errors and use standards / familiar design.
deleted 4y ago
[deleted]

residualmind 4y ago

Actually reading (and understanding, acting upon) error messages seems to be part of the learning process of every developer. And while more senior devs usually do read error messages, even they sometimes, rather than reading it will jump to behavior like "trying again a different way", before looking closely what went wrong.

hinkley 4y ago
Developers often seemed shocked that people can’t find the important error in a wall of text. A particular peeve is when the same error is reported three ways and the real error is sandwiched between others or scrolled off the screen due to spammy behavior.

ajnin 4y ago

How many interactions didn't you have, because the developer read the error message, read the Wiki, and ultimately solved the issue themselves ?

deleted 4y ago
[deleted]

zagrebian 4y ago

This just means that the error message needs to be more clear. For example, after the error itself, it could give direct advice: “PERFORM THESE STEPS: You must define ENVVAR. Go to <wiki link>. Set ENVVAR to a proper value and restart the service.” Notice the direct language. It reads like an order. The less direct the message, the higher the chances that the user will not act upon it.

dvtrn 4y ago
I’m not seeing how what the message already is any less direct or clear than what you’re saying it should be? It straight up tells you it can’t find the var and what to do about it. Can you help me understand what isn’t clear about the message as is, or maybe point out the ambiguity to someone who just isn’t seeing it? I want to write better error messages but I share the frustration of the above poster. The message tells you specifically what to do, but you’re coming back saying it’s not clear.
- lupire 4y ago
  Some people don't read anything that isn't an all-caps command. They have learned helplessness from seeing too much useless error text in the past.
- j-bos 4y ago
  I think the original error is quite clear, under normal circumstances. Not OP but I've noticed that people often get brain fog when something goes wrong and are often need BIG, SHORT, WORDS to shake out of it. Or really anything that can shake them out of the 'idunno' state of mind. But maybe if something like that became standard ut would no longet be a context switcher..
  - ckozlowski 4y ago
    I think you're spot on, and I made a similar comment above. It's easy to say "they can figure it out". Sure, in a restful state. But the people we're asking to take action already have a lot on their plate. Using plain, conversational language whenever possible with exceedingly clear steps means less mental exertion on the receiver. And since we need their help, anything we can do to make it easier on their end helps us.

Joker_vD 4y ago

Well, imagine the error was simply "RuntimeError: Environment variable not set" instead, then how much of your time would have been wasted by those dozen interactions?

grandinj 4y ago

Some developers are just lazy, and will likely need some kind of negative feedback to force them to confront their own laziness. Which can be tricky, because the degree of negative feedback that is appropriate to the person in question can range from "Polite one-on-one suggestion that you read the error message more than once before calling me" to "Full on yelling at the person in the middle of an open-plan office". Thankfully, type II is rare, but they do occur.

lupire 4y ago
Send a link to wiki. Last line of page is "if you have questions, reach out and include the keyword $THIS_PAGE_KEY in your message."
bartread 4y ago
> Some developers are just lazy I'm really lazy: if I were on the receiving end of emails with error messages that included instructions about how to fix said error I'd automate Freshdesk (or whatever ticketing system I was using) to respond with instructions specific to that error message, in the first instance, along with a note to get in touch again if that didn't solve the problem. I'd also set the ticket to autoresolve after a set period of time.

jimmytidey 4y ago

This is a context where people are used to seeing errors that they don't know what to do with. If a web app pops a well written error it is much more likely to be acted on than an unmotivated dev seeing a some (probably badly formatted) text. Every time I see an error in terminal with a link to documentation I'm delighted. And surprised.

nerdponx 4y ago
So? That's no excuse for a developer to disregard the content of an error message in their own application.
- lijogdfljk 4y ago
  It kinda is. Kinda like when documentation is so repeatedly outdated and incorrect, that when you need new information you just skip documentation entirely. Are you wrong for skipping documentation? Yea, maybe. Is it entirely expected? Yea. Based on the parent comment, at least.
- monknomo 4y ago
  And yet developers do disregard the content of error messages. Try to figure out why they disregard it. I doubt the answer is "because they're stupid". The answer probably also isn't "because they just aren't trying". What could it be? Why do people read things and react in similar ways, even if they have different jobs? If only there was some field of study that could answer these mysteries.
Kalium 4y ago
Once upon a time, I worked at a financial startup (the company is irrelevant). I created a little harness around a static analysis tool. It would fail builds when a library had an outstanding vulnerability scored as HIGH or SEVERE with a patch available. The harness put a friendly error message around it. It ran roughly as follows: > Hi! If you're reading this message, it's likely because this tool failed your build. To understand why and fix it, please click this link <link_to_internal_doc>. Below is a table that lists the packages you need to update and the version you need to update them to. The doc had at the very top in big flashing red text with siren anigifs a link to the portion that explained that they needed to update their libraries with very clear copy-paste-into-Dockerfile actionable guidance. The page also explained the broader context, such as the point of the tool and why we were doing this despite having a firewall and so on. This is where you might be delighted and surprised. What was perhaps less delightful and surprising were the consequences for me. About 4-6 times a week, I would then have a Slack conversation akin to this: Dev: Why did you break my build!?! Me: Can I see the error message? Dev: <pastes message above> Me: Thanks! Looking at the message, is there something unclear about the documentation? Does it not work? <ten minutes pass> Dev: Nope! Docs are great! At this point the conversation would end.

chillfox 4y ago

Don't send people somewhere else to learn how to fix the error. The more steps and indirection you add the fewer people will bother doing it themselves, especially if they can bump it to the developer. Make it easy for people to fix their own problems by being explicit, direct and complete. List all the steps and use formatting to make it visually easier to consume. So your error message while a far cry from the worst I have seen is also pretty far from the good ones I have seen.

starkd 4y ago
I think his point was the developer tends not to even investigate the ENVVAR at issue or visit the link. If the developer does investigate the link and still has an issue, than you have a point.
- chillfox 4y ago
  Pretty sure his problem was he got contacted about an issue he considers uninteresting, and his preferred solution is the user stops behaving like a human. Reaching for the easiest way to solve a problem first is a very human thing to do, and in this case he was easier to contact than opening up a browser and reading an article that presumably is written in the same kind of language as the error message.
  - dvtrn 4y ago
    I’m left wonder at what point does the “give a man a fish/teach a man how to fish” method of pedagogy apply in terms of ‘acting like a human’ in this context? Asking as someone who otherwise generally agrees that there are some truly poorly written errors and exceptions out there, but has also been on the admittedly frustrating end of the constant requests for help deciphering error messages that were very plainly stating what the problem is for someone who didn’t even try looking for the fishing rod.
    - chillfox 4y ago
      Sure, clearly there are people who will never try, or learn, but in general as an industry I feel like the wast majority of errors are very very far from good. Few error messages are written well, has good formatting and are self contained (can be used to fix the issue without having to seek further information elsewhere). Sometimes you see errors that contain one of those elements, but rarely all of them. There has been an effort the last few years improving compiler errors for some languages, but those same improvements have not reached applications.

lupire 4y ago

Use the error messages you wrote! Send them the link they sent you, and move on.

rjmill 4y ago

> evidence at all that they would be read I just had an idea: Put tracking info in the error URL. If your company has an internal URL shortener, that could do the trick. More practically, I feel like it helps to put an empty line before the call to action. For many people, a traceback is just noise. The empty line helps split the useful info out from the traceback. Or if it's a script/CLI (and you know the error reason) don't even show a traceback. Just print the error message to stderr, exit non-zero, and be done with it.

JTbane 4y ago

>>>“RuntimeError: Did not find ENVVAR, ensure this is set to the proper value (see <internal wiki link>) and then restart this service” I'm laughing as you could not make it clearer if you tried. PEBKAC

nkrisc 4y ago

The goal of writing better error messages isn't to help the people who never read error messages, it's to help the people who do and who you never have to hear from.

marklubi 4y ago
The trick that I've found is that each error message needs to be unique... not just the stack trace, but the actual wording of the message leading up to that. Get a screenshot or the exact verbatim of it, and you can identify exactly where in the code it originated. User reports are unreliable, but when I can pinpoint where the message originated from, it massively cuts down on the troubleshooting time.
- legulere 4y ago
  In RFC 7807 all errors get an unique URI. Message texts might change or be translated into a language you don’t understand.
  - BerislavLopac 4y ago
    To be precise, each error type gets a unique URI. A good way to take advantage of that is to have a central database of all error types, but not many companies bother to do that.
    - mi_lk 4y ago
      > have a central database of all error types do you have any example?
      - zem 4y ago
        here's ours for pytype (a python type checker): https://google.github.io/pytype/errors.html https://google.github.io/pytype/errors.html
  - shadowgovt 4y ago

coldacid 4y ago

The help desk guys are on the other side of a cubicle wall from my workstation, and almost every call I overhear about someone getting errors just convinces me further and further that people don't only not pay attention to the error message, they don't pay attention to the people they're calling to help them get through the situation either.

TillE 4y ago

I've seen this constantly over the years, people who absolutely refuse to read the simplest instructions, but instead require step-by-step hand-holding from you personally. I have no idea how these people get through life at all.

dagw 4y ago
I suspect that, at least subconsciously, they're to some extent doing that to punish you for writing 'bad' software that they have to struggle with. If they're going to suffer, you're going to suffer right along side them.
0x457 4y ago
Hey, let's jump on a quick call, so we can go through this together and maybe update docs if they're out of date?
nicbou 4y ago
I have no idea either. For example when someone asks me "how do I get a German work visa" and I reply with a link to a page titled "how to get a German work visa", which is the among the first results on Google. A literal minute later, they ask me more questions that the page clearly answers. Some people can't be arsed to read a 5 minute article you hand-delivered to them, and would rather have you type it back to them. I think that some people just have zero respect for other people's time.

onion2k 4y ago

Shouldn't the app gracefully exit with a clear message, and not bail out in a way that looks like a crash? I'd guess that the person who wrote it hooked into the error handler because that was the easy thing to do rather than bother to write a nice way to exit properly. The fact that you've had this a dozen times points to a problem with the app more than the people using it to me.

0xbadcafebee 4y ago

The problem is here: "RuntimeError:". Once they saw that, they stopped reading. "Did not find ENVVAR" [..] "ensure this is set to the proper value" [..] "and then restart the service" are also obscure and will stop them from reading. Why is the user like this? Error message PTSD. Years of staring at obscure errors full of technical jargon that are not helpful to the user, has left them scared to even look at the content of the error message. They have tried to Google these things before and failed, and now they just avoid it entirely and run for help. I'm sure there's enough detail in the link you provided to help the user. But if that's the case, it will be better for the error message to simply say: A problem occurred, but don't worry! You can fix it yourself in 5 minutes! For instructions, visit https://internal-wiki-link/spaces/BLAH/AppUserRuntimeError#A013579 Even if you expect the user to be "smart enough" to fix their own problem, they are more likely to try it themselves if you make it seem easier.

Kalium 4y ago
I tried exactly this approach! What I got was a bunch of developers copy-pasting the error message with helpful URL at me and demanding to know what they should do. The number who followed the link and fixed the problem themselves was shockingly small. Going out on a limb, I think we're all going astray by trying to parse the error messages our fellow developers are reacting to. A great many seem to handle any unfamiliar or unexpected error message by giving up, no matter how friendly or informative or helpful it may be.
- bonoboTP 4y ago
  They don't parse the error message as a natural language sentence talking to them. They take it as an opaque string, like a big error code. It literally passes through them without getting interpreted. They learned that the affordances of these error messages are copy pasting into some place: a google search box, or a chat box asking for help. But it has no affordance of "interpret as an English sentence" for them.
- 0xbadcafebee 4y ago
  If that's the case, then these people may just need training. It's likely that nobody has ever sat them down and explained that they have a responsibility to investigate their own issue. Often people feel they have to rush to get something done, and that they can't take time to troubleshoot. But if their bosses explained that, actually, it's fine if your work is a little late due to troubleshooting, they might do it themselves more often. You also may need to provide back-pressure by interacting via email/ticket.

AlwaysRock 4y ago

It's a little annoying but to be fair because most error messaging is garbage, its easy to start to ignore them. How often is the error message shown, and the little fix given, actually going to solve the problem in modern web development? 10% of the time? 25% of the time? I'd be shocked if its that high.

quintussss 4y ago

Isn't this just survivor bias though? You only hear from those that fail to read and act on the error message.

bonoboTP 4y ago

It's error message blindness, similar to ad blindness. Even if you make a great banner ad with some very useful information, or the perfect and affordable product for my life I won't see it because I mentally filter out ads because they are junk most of the time. Some people develop the same with relation to error messages because most of them are not actionable, other than "stuff broke somehow, [gibberish] blabla". Even if your error message is impeccable, it's in the class of things that are noise. If you come up to me at some busy tourist location, where I'm used to lots of scammers, I won't listen to you even if you are actually a nice person and just want to have a nice chat and we would be compatible friends. Often it is a good strategy to just ask people. Documentation and comments get out of date very fast. If you are the kind of person who reads everything meticulously and googles around, reads manuals etc. you may be wasting a lot of time. Of course there is a right balance to find. Some people err too much on the side of not thinking themselves and immediately asking for handholding, but overall it's often the right thing to do. In many cases I found that trying to reason out what was going on was hopeless, because when I eventually gave up and asked someone, it turned out that the solution was unguessable, something like "ah of course, that things is out of date, do this magic incantation, then this and that, yeah we should update the docs sometime!". A lot of knowledge is locked up inside people's brains and just spreads around as "rumors" on the grapevine. Is that state of affairs ideal? No. But it's realistic and people are going to adapt by asking first, thinking second.

BlargMcLarg 4y ago
Asking people is mostly bad habits from a culture too ingrained into the whole 'ask first' thing, and often times it is the people trying to help that are to blame. I had this recently. Many individuals like to play hero and make sure I don't get stuck because their business is an undocumented mess. Before I even read the thing and tried, they are already trying to give me the answer. When I ask 'is this documented and if so, how would it be discovered easily' their first reaction is 'no' followed by a lengthy explanation which should be in the wiki and easy for newcomers to find. And it shows when I forget a few days later because my brain never put in the effort to get to the answer and my memory is that of a fruit fly's.
Jiro 4y ago

outworlder 4y ago

I have managed to get a lot of notoriety in my company by just: 1. Paying attention to error messages 2. Reading documentation 3. Looking up stuff I don't fully understand(including googling error messages) That's it. Some people don't even read error messages at all. I understand non technical people doing that, but I've seen far too many engineers doing it. If anything doesn't go exactly as expected, they freeze. I have no idea how a person gets so far in their careers without reading error messages. Actually, I do, those people ask others to figure out stuff for them. That's way prevalent in enterprise settings. Sure, collaboration is good, but I've seen a lot of instances where there's a massive imbalance – you'll have 10 people pinging a single person to 'unblock' them. They could have spent a couple of minutes trying to figure out yourself. I'll move mountains to help someone that comes to me after having done some basic homework to try to fix (or at least triage) an issue. It very rare though. It's also amazing how many people will just go ahead without having read a single line of documentation of the thing they are working on. I've even had a developer dive in a Golang codebase without having _ever_ worked on the language. That would have been fine – that's how I learn new languages, just get accustomed, before doing some more formal training and exercises – except that he continued to not read the language documentation before asking a bunch of questions. Needless to say, the questions weren't good. And number 3... just rubber ducky everything. If you can't explain it, you don't get it. Go read up on the topic. Sometimes I'll find out that I don't fully understand something as I'm writing an email to others.

vladvasiliu 4y ago
> I'll move mountains to help someone that comes to me after having done some basic homework to try to fix (or at least triage) an issue. It very rare though. This. I actually am OK with people not figuring out even basic stuff. But please, at least try to give the impression that you've put some effort in, instead of just trying to have me do your homework while you browse facebook or whatever.
tetha 4y ago
> I'll move mountains to help someone that comes to me after having done some basic homework to try to fix (or at least triage) an issue. It very rare though. These are rare, but they also tend to be the really effective ones. We have a couple of teams who understand the stack, read documentation and read error messages. We generally don't hear of them for months and months, because they are too busy being productive. But when we hear of them, it's usually time to push boundaries of the infrastructure and the processes. They tried everything and nothing worked and now it's time to make it work.

deleted 4y ago

[deleted]

CityCobra 4y ago

Still, if you write proper error messages then at least you can figure out what the issue was without SSHing into the person’s computer and checking their logs.

bob1029 4y ago

This is a lesson I learned while being system owner of the primary user interface that runs on a semiconductor factory floor. No amount of confirmation/warning dialogs will actually stop someone from doing a wrong thing. Doesn't matter how scary the language is. Here's an approximate sample of one: "DANGER! Confirming this action may result in 8 figures worth of scrap!!!" Even if you are super careful and make sure your error messages are terse in all cases, you will still succumb to things like muscle memory among your users. I've caught myself mindlessly dismissing these while testing. How can I expect my users to be better than the person who developed the UI? That is unreasonable. It got to a point where we started removing these alerts/confirmations because it was training people to do the wrong thing in a few places. If you have part of a UI where all actions are immediate and final, the game theory changes. The moment a user enters into one of these spaces, they are much more cautious. If the user thinks the UI will save them, they may eventually tire of these protections and forget why they are there in the first place. I feel like this is very similar to the problem of driver assistance and partial self-driving capabilities today.

nicbou 4y ago
I like how GitHub asks you to type back the name of the repository you want to delete.
- bob1029 4y ago
  For GitHub scary actions, I will not hesitate to copy and paste the expected repo name on the UI. I can do this so quickly my brain does not process the consequences in time.

pizza 4y ago

I mean it kinda makes sense. When you're coding, you're constructing something. When you're debugging, you're deconstructing something. I feel like it's natural for people to take a sec to codeswitch, bc they were likely in a state of flow w/ considerable momentum up until they saw the error

llbeansandrice 4y ago

I feel like I can't get folks to open the log file and cmd-F "ERROR" half the time.

tlogan 4y ago

This is 100% correct. In theory, all errors should: explain the input, explain the problem and explain how to solve the problem (actions). And that should help and reduce number of support calls. However, error messages and actions how to solve the error are read by maybe 1% of users. The only way to improve your UI is to prevent errors and use standards / familiar design.

deleted 4y ago

[deleted]