this post was submitted on 14 Mar 2025

300 points (95.2% liked)

Mildly Infuriating

38232 readers

1021 users here now

Home to all things "Mildly Infuriating" Not infuriating, not enraging. Mildly Infuriating. All posts should reflect that.

I want my day mildly ruined, not completely ruined. Please remember to refrain from reposting old content. If you post a post from reddit it is good practice to include a link and credit the OP. I'm not about stealing content!

It's just good to get something in this website for casual viewing whilst refreshing original content is added overtime.

Rules:

1. Be Respectful

Refrain from using harmful language pertaining to a protected characteristic: e.g. race, gender, sexuality, disability or religion.

Refrain from being argumentative when responding or commenting to posts/replies. Personal attacks are not welcome here.

...

2. No Illegal Content

Content that violates the law. Any post/comment found to be in breach of common law will be removed and given to the authorities if required.

That means: -No promoting violence/threats against any individuals

-No CSA content or Revenge Porn

-No sharing private/personal information (Doxxing)

...

3. No Spam

Posting the same post, no matter the intent is against the rules.

-If you have posted content, please refrain from re-posting said content within this community.

-Do not spam posts with intent to harass, annoy, bully, advertise, scam or harm this community.

-No posting Scams/Advertisements/Phishing Links/IP Grabbers

-No Bots, Bots will be banned from the community.

...

4. No Porn/Explicit

Content

-Do not post explicit content. Lemmy.World is not the instance for NSFW content.

-Do not post Gore or Shock Content.

...

5. No Enciting Harassment,

Brigading, Doxxing or Witch Hunts

-Do not Brigade other Communities

-No calls to action against other communities/users within Lemmy or outside of Lemmy.

-No Witch Hunts against users/communities.

-No content that harasses members within or outside of the community.

...

6. NSFW should be behind NSFW tags.

-Content that is NSFW should be behind NSFW tags.

-Content that might be distressing should be kept behind NSFW tags.

...

7. Content should match the theme of this community.

-Content should be Mildly infuriating.

-The Community !actuallyinfuriating has been born so that's where you should post the big stuff.

...

8. Reposting of Reddit content is permitted, try to credit the OC.

-Please consider crediting the OC when reposting content. A name of the user or a link to the original post is sufficient.

...

Also check out:

Partnered Communities:

1.Lemmy Review

2.Lemmy Be Wholesome

3.Lemmy Shitpost

4.No Stupid Questions

5.You Should Know

6.Credible Defense

Reach out to LillianVS for inclusion on the sidebar.

All communities included on the sidebar are to be made in compliance with the instance rules.

founded 2 years ago

MODERATORS

[email protected]

300

Oops, something went wrong! (i.imgflip.com)

submitted 4 days ago* (last edited 3 days ago) by [email protected] to c/[email protected]

105 comments fedilink hide all child comments

This is a rant about how so many apps on many different platforms (TVs, mobile devices, computers, etc...) have decided to not actually show detailed errors any more. Instead, we get something along the lines of:

Oops, somehting went wrong. Please try again later

.... and then, well, we get to figure out what just happened and what in the world we need to do about it. And good luck with that, since you have no idea what just failed.

Why software developers?!? Why have you forsaken us?

EDIT 24 hours later: I feel like I need to clarify a few things:

I've worked for 8 software companies over 30+ years. I know why putting a DB error into the message users see is a bad idea. I know that makes me uncommon, but I still want more info from these messages.

You all are answering as if there are only two ways this can work: (a) what we have now (which is useless), and (b) a detailed error listing showing a full stack trace. I think the developers could meet me half-way.

What I want is either (a) "Something went wrong on the server, you can't fix it, but we will" or (b) "Something on your end didn't work. Check your network or restart the app or do something differently and then try the same thing again". And if they're blocking me because I'm using a VPN, fucking say so (but that's a whole separate thing...)

Some apps do provide enough info so I have a clue what I should do next, and I appreciate the effort they put into helping me. I think what I am really ranting about is I want more developers to take the time to do this instead of reporting all errors with "Oops, try again". (If the error is in their server, why should I try again?) Give me a hint as to the problem, so I have something to go on.

Cheers y'all. Still love you my techy brothers and sisters.

top 50 comments

sorted by: hot top controversial new old

[–] [email protected] 13 points 2 days ago

[–] [email protected] 62 points 4 days ago (6 children)

Error messages are a common way for hackers to gain information about a system. Useless error messages are recommended for security.

If you enter your username as Robert''); DROP TABLE Students;-- giving the error "Oops, something went wrong" is better than "NoSuchTable: 'Students' Table doesn't exist in the database" because now the hacker knows you're using a database that interprets SQL commands and inputs aren't being sanitized.

Hacking programs like Burp Suite have functions that spam sites with all kinds of garbage data and uses error messages and delays in response times to highlight potential vulnerabilities.

[–] [email protected] 3 points 2 days ago

Same logic as "keep it closed source for security".

[–] [email protected] 7 points 4 days ago* (last edited 4 days ago)

Yeah but most of these errors don't even give out a uuid that could be used to relate the error to logs to be resolved by someone.

Not that that someone exists anyway. Let's face it the entire industry is a massive joke and a pile of shit and with AI coming fast and hard soon you won't even get the privilege of venting to a call center person about it.

You'll vent to some made-up chatbot named veeblezorp and he will give you an impromptu therapy session about the state of the world. Your computer/tablet/phone/app still won't work properly and veeblezorp will try to get you through the stages of grief about that.

Just unplug it and don't plug it back in again. Go for a walk. Play with the dog. Hug your children. Stop buying crap online that scales up infinitely to take new customers (and their dollars) but is forever stuck at the sub-garage startup level when it comes to support.

[–] [email protected] 10 points 4 days ago

This comment belongs on masterhacker

load more comments (3 replies)

[–] [email protected] 3 points 2 days ago

The developers are meeting you halfway. They told you something went wrong, They have the stack trace in the logs.

Being a reasonably knowledgeable individual you could make use of the deeper information at least scratch your itch for what happened, in the end there's nothing you can do about it there's a back end problem. But giving that more detailed information to the end user is a fool's errand.

Let's say we pick a simple one, the database connector is down. End user gets a message that the database is unconnectable. Forum start to light up with worries of people losing data. Armchair conjecture about backups and data loss and updates abound.

Realistically the VM host at Amazon had a critical update and got updated, but failed to come back up as they do occasionally and someone needs to go and stop and start the instance to get the database online on new hardware. It only takes 15 or 20 minutes.

Now you've got thousands of people in your forum pissed off about something that is only mostly out of your control.

Now let's replace that error with oops something went wrong.

The people on the forms mention that it's down they ponder about what could possibly be wrong, But without anything to go on it fizzles away, The site comes back up and people just chalk it up to regular internet shenanigans.

The company didn't get any benefit from giving the end user more information. Your average user just got their knickers and a twist. And a handful of knowledgeable professionals went wow that sucks sorry guys.

[–] [email protected] 64 points 4 days ago (5 children)

Because 99% of the time these errors are caused by something on their end that the user is unable to fix, even on the off chance that they understand the problem in the first place. So there isn't any need to give you more information than "something went wrong, please wait a minute and/or try again".

[–] [email protected] 32 points 4 days ago (11 children)

OK but then inherent in what you're saying is also the message, "... and don't contact us about this, because we don't want to deal with it" which is also mildly infuriating to me.

[–] [email protected] 2 points 2 days ago

The “we don’t want to deal with it” part is something you’re attributing to them with no evidence. As a former SRE, I can guarantee you they are dealing with it.

[–] [email protected] 20 points 4 days ago* (last edited 4 days ago) (8 children)

Iit’s an internal error that is not handled properly. They don’t want to tell you the exact error message and detailed information around that, because it would expose the internal state of the backend and that would be a security issue. There is really nothing more that they can tell you, except that a developer needs to look at this (and possibly thousands to tens or hundreds of thousands of similar logged errors) and they probably already are.

load more comments (8 replies)

load more comments (9 replies)

[–] [email protected] 1 points 2 days ago (1 children)

Blanket "99%" statements are unfounded. I have had countless issues I was able to fix through error messages and some without.

Source your claim.

[–] [email protected] 2 points 2 days ago (1 children)

I can’t speak for the other user’s claim, but I’ve worked at Facebook, Google, and LinkedIn, and have written plenty of error messages. When I write a message like these, it’s specifically because the user can’t do anything about it. I’ll log the error to our internal error tracking systems with actual information about it, then give the user a generic message.

If it’s something the user did wrong, and they can fix it, I’ll absolutely give them a message saying that. Usually I won’t even let a user submit a bad request, but sometimes users will bypass frontend restrictions to submit it, so the server always needs to validate it again anyway. The fact that plenty of users won’t even read the message I write is kind of annoying, but at least the users who do read it will know how to fix it.

I’ve tried sending detailed error messages before, and that invariably results in users submitting support tickets and forum posts for things that aren’t helpful. You learn pretty quickly what kind of messages are helpful and what kind aren’t.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

I would appreciate the detailed error responses even if the developers don't think it would be of use to them.

When a project has unexpected downtime, and they do a postmortem explaining exactly what part of their infrastructure failed, what steps they took to resolve it, and how they will prevent it in the future, that is great.

I appreciate transparency. Of course, to expect this from a large corporations is expecting a pig to fly, but detailed error messages are one more step away from "We are the cloud" and one step towards "We are real people providing a service which operates on server infrastructure consisting of..." Its transparent, down-to-earth, and respects people who do want to see behind the scenes.

One company I used even had a white paper explaining their infrastructure as a whole.

This all may not make you more money, but I prefer this to instead treating me with the bare minimum insight into the inner-workings.

[–] [email protected] 1 points 2 days ago (1 children)

I want you to really pay attention to the last paragraph of my previous comment. It’s the most important part. You might like having more information that doesn’t help you, but that comes at the cost of thousands of useless tasks and posts that all have to be manually closed. It’s not only not helpful to give the user detailed error messages in a lot of cases, it’s actively harmful to a business. It doesn’t make any business sense to tell a user that a cache layer host or a db shard is down. As a developer of these kinds of systems, I’m not going to give extra information that you don’t need just to make a few users happy that they get a peek under the hood if it means hurting our support staff.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

How is a user sending a support request containing the information: "Site not working. Error message: A surge in requests is overloading the server. Everyone is being ratelimited." Any different from them just saying "Site not working."?

If they were going to submit an issue for a problem that is already known, why would the error message significantly change the difficulty of dealing them?

[–] [email protected] 1 points 2 days ago

Because if there’s no error code or specific message, they’re far less likely to submit a ticket. The reason these messages often say, “try again later” is because that is the appropriate action for the user to take.

load more comments (3 replies)

[–] [email protected] 12 points 3 days ago

I agree that it's (weirdly) uncommon to be the one saying "please give me more info about the error!"

A simple error code can be endlessly helpful (bonus points if there's a corresponding support article explaining common codes)

Even if some codes are only useful to internal support, it's handy to be able to search an error code and see "oh I can just jump straight to submitting a ticket/calling their support" or "oh, this fix might work"

[–] [email protected] 13 points 3 days ago (2 children)

As a developer of many years I hate to tell you sometimes that it's all the information we have when something breaks also. Most code is a god awful mess. Thankfully I love a good mystery.

load more comments (2 replies)

[–] [email protected] 2 points 2 days ago* (last edited 2 days ago)

Because the error message would be meaningless for 99% of people. Expected errors are already handled correctly, but unexpected errors like these would say something obscure like “couldn’t read property ‘count’ of undefined”. Very useful

[–] [email protected] 9 points 3 days ago* (last edited 3 days ago) (1 children)

I hate the oops part. When you get an error message and it's not even professional or technical but flimsy, I lose all respect.

At my job an Oops design was suggested. I'm glad I was able to convince us to implement it differently, without that shit tone and unprofessionalism.

[–] [email protected] 5 points 3 days ago

professionalism is so last millennium. we're hip and young and human. and definitely your friend.

[–] [email protected] 19 points 4 days ago* (last edited 2 days ago) (2 children)

What are you planning to do with information about the error? It’s not like these places have customer support. Usually it’s something like a caching layer failing, and there’s literally nothing you can do about that.

Edit after reading your edit:

I still don’t see why you want more information here. Those kinds of errors are almost always server side errors, and reporting more detailed information won’t help you.

You asked “why should I try again?” Answering this would almost always be unhelpful to the vast majority of users. “Try again later, because one of our cache layer hosts was down, and by the time you try again, it’ll have been taken out of the load balancer rotation, so you likely won’t hit that host on your next try.”

It would also cause more confusion with a non-insignificant portion of your users. Users start to misunderstand copy when sentences start to exceed eight words. “Something went wrong. Try again later.” That’s understandable by 100% of people according to that study.

Even saying “there’s nothing you can do about it” will probably be taken negatively by a certain portion of users. Not saying it’s incorrect, just that when you write an error message (or any microcopy for that matter), you should avoid sounding negative to the user. “Something went wrong. Try again later” conveys all the information the user needs in a way that won’t be misinterpreted.

[–] [email protected] 15 points 4 days ago (11 children)

If it's an error code I've worked around before, apply same troubleshooting.

If its a new errror code, search the error code to see how other people solved it.

If no one else has solved the error code, try analogous troubleshooting, post results online with the error code name, successful or not.

load more comments (11 replies)

[–] [email protected] 1 points 2 days ago (1 children)

By nature of software consisting of a client and a server, there are certainly errors that can be bypassed on the client side.

Server side software does not mean "there is literally no errors that are dependent on client input." That's ridiculous to think, but pervasive in this comment section it seems.

[–] [email protected] 2 points 2 days ago (1 children)

I don’t know why you think what I said means that. These error messages are never used on data validation issues. At least, I’ve never seen a data validation issue return an error like this, and I would never write an error like this for a data validation issue.

These messages come from 500-series errors. Usually caching layer errors, load balancer layer errors, edge termination layer errors, or db layer errors. In other words, there was probably nothing wrong with the request, it just couldn’t be fulfilled successfully, hence the “try again later” part in a lot of these messages.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

These error messages are never (sic) used on data validation issues.

You are incorrect. I have had issues that were exactly that. Such as a password that was failing to be accepted and then giving generic error responses, which I then had to trial-and-error brute force to find which part of my password they weren't allowing on the backend.

You stance might become easier to defend if you avoid absolutes.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

Read the next sentence.

It sounds like your problem is not with these errors in general, but with specific software that uses generic messages when not appropriate.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

The error is unnecessarily vague.

If the message is supposed to mean "There is an internal error that is of little use to you, so you can only wait while we fix it. Try again in 10 minutes." Then say that. That tells me a developer made a conscious decision to classify the failure mode as one which I cannot fix. They are explaining to you what type of error they perceive it to be.

Instead we have "Something went wrong. Try again later." which doesn't say that directly. This could just be them designing their systems as though every user is incompetent, and denying you the information to fix the issue yourself.

You wouldn't know, because it doesn't just tell you directly.

[–] [email protected] 1 points 2 days ago (1 children)

It is intentionally and, I would argue, necessarily vague.

First, there is no time frame for these kinds of errors. If it’s just a cache host that’s down, you could retry right now and the load balancer would probably have taken that host out of rotation already. If it’s a primary db that’s down, that may take 5 minutes. If there’s no replica to promote, it might take 30 minutes. If the whole db layer is down, it might take an hour or two. If an entire release needs to be rolled back, it might take a couple hours. There are just too many scenarios and too many variables to give a useful time frame.

Second, you might appreciate an error message like that, but these error messages aren’t written for you and they’re usually not even written by developers. They’re written by designers and translated into many languages. They need to be concise, easily understood, and not easily construed as derogatory or malicious in any language. They are written for the broadest audience. You are not the broadest audience.

Third, we have to design systems as if every user is incompetent and/or malicious, because many of them are. Let me give you an example. I once got an email from another engineer using an internal system my team wrote. He said, “hey I’m getting this error, can you help?” He attached a screenshot showing an error message that read, “Your auth token has expired. Please refresh the page.” He was a senior engineer.

Fourth, and I cannot stress this enough, there is almost always nothing you can do when you hit an error like this. Any information given to you for the vast majority of these kinds of errors would be entirely useless to you. You cannot promote a db shard yourself. You cannot bring up a cache host yourself. You cannot take a host out of load balancer rotation yourself. The only reason this information could possibly benefit you is to satisfy your curiosity.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

There is no time frame for these kinds of errors

If I was are able to isolate the issue to, for example, expired certs, I could absolutely give you a ballpark answer on how long it should take/when it might be back up. It doesn't need to be very precise, but I have accessed websites only to be shown an error with zero idea whether this is a multi-day event or something I can wait five minutes and it be fixed.

...they are written by designers...

Cooperation with a developer would help here.

They are written for the broadest audience

If you write only for a child, your usefulness ceiling is that of what a child could understand. You could have your obvious boilerplate message, and then under that provide more information.

...not easily construed as derogatory or malicious in any language.

I feel as if this is a simple problem to avoid.

We have to design systems as if every user is incompetent...

See the bottom of this post

there is almost nothing you can do when you hit an error like this.

If the company believes so, then write that part in. Otherwise, it isn't stated that such is the case. It would be one more sentence on the boilerplate section.

Overall this has to do with what you are optimizing for. Its clear to me that many businesses believe useless boilerplate error messages are most cost effective. If you want to be most cost-effective, then cutting corners on the error messages likely saves time with few financial downsides. But It doesn't have to be this way.

Designing systems for the lowest person on the totem poll isn't without downsides. I have used Linux systems that made the bootup hide all log messages. This means that people that can actually fix a broken system using the logs, are going to have a harder time, as you just hid away all the moving parts and complexity from the end user. Some machines I wouldn't have been able to fix were it not for the detailed logs.

Or we could talk about privacy. Nearly everyone can use a computer. Great right!? But how many people actually understand the privacy implications of using a machine that is controlled by a closed source corporation. Of entering load of data into that machine? Very few.

You can design a system for idiots. But you don't have to. There are things in life that have prerequisites. If someone comes over to my computer and asks "What's that" on a kernel log output, I'll ask them, "Do you know what a kernel is". If they don't, then I will tell them not to worry about it. My explanations are not for everyone. Neither are my software.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago) (1 children)

An expired cert means the browser would show an error message. I can’t send you any message if my cert is expired, because your browser won’t trust the connection.

UX designers have completely different skill sets than software engineers. At a small company, someone might do both roles, but at a company like Google or Microsoft, those are two different job titles. They do work together. In my experience, there’s a general consensus between both high level designers and high level engineers that giving the user useless information in an error message is a bad idea. There’s a reason these messages are similar across lots of companies. It’s because they are the best option for the business. If we need extra details from the user, we’ll have it printed in the console and tell them to open the console. That is incredibly rare, and basically only ever used for a network failure scenario in a service worker.

You can design your software for tech gurus, but you shouldn’t expect Microsoft Teams to be designed for tech gurus. Their customers are the general public (not super tech savvy), so they design for the general public.

You wrote “useless boilerplate error messages” in your comment, and I’m telling you that the useless part cannot be changed. You want useless detailed error messages. Good for you. Write software that gives you useless detailed error messages. Tell everyone about it and see how the general public reacts. I’ve been working in big tech for 17 years, and I am telling you from all of my experience that the general public will react poorly.

You’re upset that the information needed to fix the issue is not given to you, but you aren’t the one who needs that information. You’re not going to fix the issue. That information absolutely is provided to the people who need it, the engineers. In your metaphor of the Linux user not seeing the boot logs, you are not the Linux user. You don’t have access to the systems that need fixing, so what good would showing you the error log do? Again, the only benefit you would get from that is satisfying your curiosity. Tell me, how are you going to remove a downed host from a load balancer rotation at Google? Even if you had the ability to do that, you still don’t have permission.

Software devs need to make a choice. When we include details, people complain and post useless bug reports and forum posts. When we don’t include details, a much smaller number of people complain, and generally we don’t get useless bug reports and forum posts about it. Which one would you choose?

PS: the reason you feel that avoiding derogatory or abusive/malicious language in many different languages is easy to avoid is because you’re not a high level UX engineer. Fun fact, ChatGPT, when pronounced in French, sounds incredibly similar to “chat, j’ai pété” which translates to “cat, I farted”. Or, how about sending a “fatal error” message to a nurse?

[–] [email protected] 1 points 2 days ago (1 children)

expired cert...

Yes. Bad example. Pick any other number of examples. You can probably put a useful time range.

Best option for the business

Already commented on that. They believe it to be so, I don't agree with that choice.

You can design your software for tech gurus...

It doesn't have to be either or. Error messages can have a baseline of mild computer knowledge, and stretch up to people who know what they are doing. You can cater to both.

Useless boiler plate error message

It doesn't have to be utterly useless. Just because you can't fix anything from where you are doesn't mean you can't benefit. If the error is deemed unfixable for customers, give a timeframe of when it should be fixed and the intended course of action (what should they do if its not back up soon and they need it to be up). Useless is a choice, but its also subjective. You may find "Something went wrong. Try again later" as not useless. I deem it so.

you are not going to fix the issue

Unfounded assertion. I have fixed server-client issues before as the client. Let me repeat it: I have fixed server-client issues as the client. There are of course issues I can't fix

I think our disconnect partly comes from the fact that I am discussing this from a point of view of server operators being fallible. If in theory they always know what is fixable only on the server and never make a mistake in that regard, then we fall back to make a useless error message more useful. But they do make mistakes (or are purposefully hiding information so you don't know how to get around the error). The Linux example. It would be very easy to justify that in the same way that companies could justify a useless error message for something which could actually be fixed. How many people are going to look at the initframfs logs and know how to chroot in, edit the initramfs init script, and then rebuild the cpio and shove it in boot? Probably less than those that don't.

You could use this as a justification to hide it completely, but also harm those that could fix it, and also harm error reporting as the users machines just don't boot the distro. I disagree with this decision.

PS

if that affected ChatGPTs popularity, I couldn't tell.

So I'll round it all off with this: improve the error messages as a whole. Add contact information, time till likely fix, course of action (try again later is vague crap). The messages feel like an unhelpful wall, the error equivalent of a chatbot responding to your pleads for support. Also, you might not always be correct in whether something is fixable or not. You could add the detailed error information near the bottom, if people don't need it then no harm. If people do then its useful. Not adding it and then it being of use could be worse than adding it and it just never being necessary.

I think this topic is wrung out dry.

[–] [email protected] 1 points 2 days ago

I think you’re trying very hard to ignore all the negative things I’ve told you users do when you include too much information. Maybe just go get a job at one of these big companies and submit a diff adding this information, then read why your diff gets rejected. I’m literally telling you the reasons big companies do this, and you just refuse to believe me. Maybe you’ll believe them.

[–] [email protected] 6 points 3 days ago

Let's talk about the growing number of websites that won't work with a vpn. Even a local government website won't work.

[–] [email protected] 7 points 3 days ago (3 children)

The why is easy. As others said, the vast majority of error messages are entirely useless for you, the user, because there's not a single thing you can possibly do to address it. What are you gonna do about a database connection issue, or bad cache, or broken Javascript? Nothing. So don't worry about it. Besides people are less panicky when they see an oops rather than a stack trace or a cryptic error message.

And don't worry, people who know how to write up useful support tickets and bug reports know how to do it even when all they can see is an "oops". Builtin browser dev tools will have information they can use to help the devs.

[–] [email protected] 11 points 3 days ago* (last edited 3 days ago)

the vast majority of error messages are entirely useless for you

Hard disagree. Maybe half, at most. And most importantly, if a user can't do anything about it, what's the difference between a "error code 487" vs "oops there's an unspecified error"? What's the harm in showing an actual error code?

The VAST majority of errors I see are connection issues, or some of my VPN or adblock stuff causing me to be denied access to the website. That's all stuff I can fix. And it would be a lot faster if I didn't have to trial-and-error my way to the actual problem first.

[–] [email protected] 1 points 2 days ago* (last edited 2 days ago)

Ridiculous take. I have debugged countless issues. Those that spit detailed error messages are typically far easier to debug than those that don't.

For example, returning nothing but exit code 1 to indicate failure. This gives zero information about the reason behind the failure, and only could be acceptable if your program is so simple as to only have very few failure modes.

I have solved issues by cloning the source code and reading it to understand the issue.

Don't relegate everyone to the same fate as those so utterly ignorant they can't look up an error code.

As for the bugs you can't fix? Why do you think Cloudflare tells you when its the website having an issue, and not your browser or them? Knowing the issue isn't something you can change, avoids spending time trying to fix an issue that you have no control over.

People who can will write up a bug report anyway

And report what exactly? Your program gives zero information has to why it failed? Now you have dropped the responsibility of figuring that out from the code, which tends to know far more about its failure state, to someone observing from afar. Its inefficient and ridiculous.

I disagree with you across the board.

load more comments (1 replies)

[–] [email protected] 15 points 4 days ago (3 children)

Users ignore error messages.

I have seen my users request support, proceed to demonstrate the issue they're having, and click through error messages so fast there isn't even enough time for me to say "WAIT!" Forget about being able to actually read even one word of the message before it's dismissed from the screen.

They treat the error messages like they are just an annoying mosquito to be swatted away as quickly as possible. This despite the fact that the whole reason I'm standing behind them is so I can see what it's going wrong and, you know, read the error messages.