alt Hacker NewsHopefully this becomes a reversal in the trend of giving less and less context to the user.
I'm not against the considerations of the article regarding the user and its state of mind, but please do add as much technical detail as possible!
Even if an error message is a cryptic error code, that's better than a "Something went wrong" message. This is not better, or even friendlier, UX. An error code can be referenced, can be searched on the internet, can be passed around on a ticket or on a call... add parameters to your error template, reference the name of the file, the item name that does not respond, the HTTP error code... just give the user some transparency, some agency. Help the client build up a mental model of the error: when / how / why might it be happening.
I'm somewhat fond of including a UUID for that reason. As long as they can copy-paste it into Google, they can get results that are precisely the errors from your application, unlike "error 55324". The same works internally: zero ambiguity which system it came from, and it's trivial to find the full history of the error (message). It's not great for verbally communicating tho.
But yes, I can get behind making things nicer to read and less technically scary, but include enough detail so that people can solve their own problems if needed. There's a decent chance that the software will outlive your desire to support it.