Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the Fastly outage can teach us about writing error messages

onlineornot.com

Post reply on HN
Print view View original

101–110 of 137 posts

Re: What the Fastly outage can teach us about writing error messages

#101

Post by rantanplan »

marcosdumay wrote: post #12
hvocode wrote: post #3

I've had more than one intern or young engineer that I've had to teach to resist the urge to put witty comments and jokes in project docs, comments, or errors. Especially in error messages or things that can be exposed to users/customers. Even if it's an error you think only the dev team will see, you never know if it will make its way out to audiences you didn't intend. Somehow I doubt people faced with this error m…

I'd say that some safe joke on the end of your error message is perfectly fine, as long as you are perfectly clear where the problem is. Just be very sure not to unintentionally blame the user. It is fine even if the user won't get the joke. Software is a highly personal and creative thing, it should have a personality. The everything gray enterprise spaces have gone too far already. Also, I really miss Linux yelling…

> Software is a highly personal and creative thing, it should have a personality

Not it isn't and it shouldn't. The process of creating the software is; huge distinction.

The product of your efforts should not have a personality or feel personal, it should just work as intended. Software is hard as it is and we don't need to make it more whimsical. A little experience can teach us, that whether we like or not, it will ultimately exhibit its own whims anyway.

Re: What the Fastly outage can teach us about writing error messages

#102

Post by manuelmoreale »

rantanplan wrote: post #101
marcosdumay wrote: post #12

Earlier quoted context omitted.

I'd say that some safe joke on the end of your error message is perfectly fine, as long as you are perfectly clear where the problem is. Just be very sure not to unintentionally blame the user. It is fine even if the user won't get the joke. Software is a highly personal and creative thing, it should have a personality. The everything gray enterprise spaces have gone too far already. Also, I really miss Linux yelling…

> Software is a highly personal and creative thing, it should have a personality Not it isn't and it shouldn't. The process of creating the software is; huge distinction. The product of your efforts should not have a personality or feel personal, it should just work as intended. Software is hard as it is and we don't need to make it more whimsical. A little experience can teach us, that whether we like or not, it wil…

> The product of your efforts should not have a personality or feel personal, it should just work as intended.

Genuine question: why it can't have both? I know it's hard to convey tone on the web but I'm asking the question because I'm genuinely interested in knowing what you think.

I personally think you can create software the right way, ship something that works and still incorporate some personality and make it less boring. I don't see why the two can't live happily together.

Re: What the Fastly outage can teach us about writing error messages

#103

Post by vort3 »

calvinmorrison wrote: post #20
aniforprez wrote: post #10

Reminds me of the quintessential tweet about error messages https://twitter.com/cherrikissu/status/972524442600558594?s=...

Right up there with Slack etcs fake loading messages "Gearing up the dildonator" "Implicating the fairies" "Hogtying George Bush" Dude - just give me a spinner or a progress bar, and if something errors during the load out give me some sort of stack trace or error ID I can use to help

Once I was at /r/androidapps and someone made a new app, asked for feedback, and «experienced devs» told OP something like «instead of „fetching data“ you should be using „getting everything ready“ because it might scare users to think that app is collecting their data».

Are people really that dumb? I'm afraid to use apps made by those people.

Re: What the Fastly outage can teach us about writing error messages

#104

Post by bandie91 »

foxpurple wrote: post #36
andyfleming wrote: post #21

Earlier quoted context omitted.

One of the reasonable reasons why errors often get returned generically is because of security though.

Exactly usually the real error message behind the “oopsie” is a stack trace containing sensitive information and environment variables. It is no use to the user since they can’t do anything and is actually dangerous to give out.

aws exceptionally performs well in this question: in some IAM-related (permission management) API error messages contains encrypted details so it does not leak sensitive data but the support can decrypt an analyze it if the user pastes it back.

Re: What the Fastly outage can teach us about writing error messages

#105

Post by aembleton »

sschueller wrote: post #76
userbinator wrote: post #41

Unfortunately the majority of internet users aren't trained in the art of reading HTTP status codes I think the majority know what 404 is, and possibly 403, but I agree about the more obscure ones. That said, I don't think it's a bad idea to rely on the "default exception handling behaviour" that the majority of users, even non-computer-literate ones, will have: they'll retry a few times, see that it doesn't work, an…

If we keep dumbing down the world for everyone instead of teaching those who don't know we will destroy ourselves. People are not stupid and if we keep assuming it we are doing a disservice to all. No more www, no more protocol in the address bar and apple is selling iMac colors in it's commercials...

How will it destroy us?

Do you think we should use hex or binary instead of their ASCII or UTF-8 equivalents? After-all, ASCII must be dumbing down as it makes it easier for non specialists to read.

Re: What the Fastly outage can teach us about writing error messages

#106

Post by aembleton »

denysvitali wrote: post #83
sschueller wrote: post #76

Earlier quoted context omitted.

If we keep dumbing down the world for everyone instead of teaching those who don't know we will destroy ourselves. People are not stupid and if we keep assuming it we are doing a disservice to all. No more www, no more protocol in the address bar and apple is selling iMac colors in it's commercials...

... and blending the search eith the address bar. I spent a good 1 hour to explain the difference to a tech illiterate on why typing "mywebsite.com" was different from typing "mywebsite com" and picking the first result on Google. I'm not sure he understood, but I really have to admit that this trend of dumbing down things is only make them worse, in a way.

They'll understand when they try and buy airline tickets that end up going through some third party with a 'service charge'.

One of my friends has recently learnt that lesson when she went to buy flights on Ryanair; just typing that into Google and clicking the first link. £30 service charge.

Re: What the Fastly outage can teach us about writing error messages

#109

Post by amalcon »

timeinput wrote: post #61

Just today I had some code that helpfully said "should never get here" and aborted. It left us to figure out what the possible options of how we could end up in that spot "we should never get to". It was maddening because it's ~12 year old code that had some library updates. A little bit more help like the error code or really * anything* would've been helpful.

A couple of years ago, I redid the error code definitions in an internal C++ library. The error returns were of the form:

  -__LINE__
which, if you know C++, means your error code is just the negation of the current line number. That's super convenient when writing. It's really annoying when someone actually sees such an error code and emails you about it -- because they obviously can't do anything with it in software. The obvious problem is that the semantics of an error code depend on the software revision they built with, but you also need to figure out which source file has an error return at that line that the user could have reached at their context.

The new error codes are almost as ergonomic to write (involving a little splash of code generation to make it so, not ideal but worth it). However, they can actually be handled in software and there's a functional perror-equivalent.

Re: What the Fastly outage can teach us about writing error messages

#110

Post by nottorp »

The problem with writing user friendly error messages is in a lot of cases you have no idea what context they'll show in. I mean, do you think they could have predicted yesterday's particular problem at Fastly?

Better to give some plain debug info than tell the user "have you tried turning it off and on again?" in my opinion.

Post reply on HN