I quit Google for DuckDuckGo and I’m not going back.

AI isn’t better than search engines, Google is worse than AI.

There’s no way that’s its real name. That sounds like a furry porn artist’s nickname.

“You are only allowed to express yourself in ways approved by the state.” - Free speech absolutists

Ok, then how about the directional circle, solid pedal, and liquid pedal?

“Refreshingly abstract.”

xD

Surprise of the century right here.

/s, in case that’s not obvious.

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?

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.

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.

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.

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.

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.

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.

I just finished rereading this. The ending is so depressing.

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.

The republicans’ new plan is: Every Child Left Behind.

If you’re passing a string, and you don’t know what currency it is, you have the exact same problem as passing an int and not knowing what currency it is. USD’s smallest denomination is 1/10 cent (gas stations usually charge in tenths of a cent, and half pennies are still legal tender, even though they’re not minted anymore), so the string representation in your examples would be exactly the same for USD and Dinar.

I agree that the best way to represent it between server and client is as a string, but that doesn’t work when you need to perform calculations, so in that case, the best way to do the calculations is to use the smallest denomination, then use banker’s rounding on the result, then use the int for storage and turn it back into a string representing the default denomination for transit. Or, just use ints representing the smallest denomination everywhere except displaying to the user. Even JavaScript can handle integer arithmetic.

Source: I’ve also done fintech for loan and retail companies. Yes, there are definitely a lot of gotchas, so using integers is best when you need to do calculations.

Every currency has a smallest denomination.

Or, use the smallest denomination. In the US, that’s typically tenths of a penny. So, $1 = 1000. Then everything uses integer arithmetic.

Of course, JS doesn’t actually have integers, so yeah, strings are probably best.

It would be a lot more troubling if screaming kids didn’t make you soft.