Comment by dkarl | Hacker News Reader

Comment by dkarl | Hacker News Reader

> However, as data from that external feed was unavailable, the price of the value of the Index instead defaulted to -1

To me, this reeks of a couple of bad experiences I had repeatedly as a back end developer coordinating with the front end:

1. Demanding that my services always returned correct-looking data, even if it wasn’t available, because they couldn’t (or wouldn’t) handle errors. The story always went like this: if a service returned a 4xx, it would trigger an exception in their front end code, and they didn’t want to tackle the complexity of handling potential errors from a bunch of different back end services. I’ve had this one get escalated to management before, who fortunately supported me.

2. Resisting efforts to ensure that potentially dangerous values were displayed in attention-getting ways. Anything that didn’t look aesthetically harmonious was liable to get “fixed” without any consideration for why it was presented in a visually jarring way in the first place. As a back end engineer I sometimes lost this battle, since it was outside of my jurisdiction, but when I could, I looped in users or a product manager to help stop the madness.

Maybe not as bad, but similar ... I've had a frontend dev say they needed to see designs from the designer before they could add any kind of error message or indicator. The status-quo is just silence, the page just stops doing anything. This is not unusual for various SPAs I've seen around the web. It is unfortunately a typical experience to click something ... no response? click again? wait how long? refresh? hello?

Have the designer design it, sure, but until that happens, you have to show something for auth expired (tab suspended for a long while), connection failed (flaky wifi), or 5xx from service - as much as I may try to make that never happen, it is possible (database failover for a few seconds?), and the design can't just be "there shall be no errors", you can't decide that.

That's often a problem with designers -- they only make a happy flow and only the end of it. No in-between states, don't understand the latency and errors exist, don't dig into boundary conditions and edge cases. It's a typical no-my-job-svg response to boot the problem upwards so their manager will make them aware of those pesky things.

A few decades ago, we chose the most awful color combinations for the UI of an internal system to encourage the designer to get on with it (they wore multiple hats). By the time I'd left a year or so later, the people using the system had not only accepted these disturbing choices, but claimed to have grown fond of them.

Stockholm syndrome

Google's internal Memegen platform used to have a disturbing amount of #FF00FF in the UI. Since it was internal and not well funded, there was no designer associated with it. The only full-time engineer at the time asked a 20%-er if #FF00FF looked good, partially as a joke, but not knowing the 20%-er was color blind. The 20%-er responded with a strong positive. The full-timer thought that the 20%-er was saying that it would be funny to launch that way as a joke, so all accents in the UI became memegenta.

Source: was a memegeneer.

What in the world is going on with Google search.

I Google'd "#FF00FF" to see how bad it was but was instead returned with a rather pleasant blue. Confused, I tried again. I got a completely different color. Same exact search. Different color. I've done the same, simple "#FF00FF" search and I'm up to five different colors with none of them being magenta.

How do you fuck something so simple as a HEX color code up?

(Hilarious story by the way. For a hot second when I saw the blue come up I thought maybe I was colorblind, too.)

You're right, that's really weird... Initially didn't see that 'cause I don't usually include the '#' in my searches so it just comes up with the colorhexa result (which is clearly more accurate lol)

Hah, I just tried it and got a nice green color. Wtf Google? They really are phoning it in on all levels these days.

DDG showed the correct color fwiw.

Perhaps it’s just the Bard painting an artistic impression of Gemini using AI.

There's a long history of Memegen trolling for the lulz.

Here's a color link so nobody else has to struggle: https://www.colorhexa.com/ff00ff

> if a service returned a 4xx, it would trigger an exception in their front end code, and they didn’t want to tackle the complexity of handling potential errors from a bunch of different back end services

I’ve seen this when the frontend team is building a fat client/smart client/Single Page App but they really want to be building a thin client/dumb client/server-rendered app. Basically it’s a technological mismatch, and client teams feel a lot of pressure to build an SPA but don’t like/want/need the extra compexity that comes with it.

I'm working on a project where this choice is relevant. Could I ask what you feel should be considered when making this decision? Thank you!

Oh man, I would LOVE for all APIs to always return real HTTP response codes. It's crazy frustrating to get a 200 OK with an empty object or something instead of a payload with the expected/agreed-upon format. If someone can parse/handle a response from an API they can absolutely add a bit of code to handle a handful of response codes.

The ambition to hide errors from users for example is just completely unhelpful if you think about it.

"Something went wrong". Sure, many or most users won't be helped by a specific error message, but they can use this message to ask someone how does. Especially if large tech companies just forget to offer support, a sensible error message is better than nothing. Sometimes error messages lead you down the wrong path if you don't know the intrinsics of an infrastructure, sure. But I still don't know which brain is responsible for the "guideline" to hide some essential from users. It is just objectively wrong.

It would be childs play to hide the "ugly information" in an extra menu, window, popup or anything. But doing UX isn't an excuse for bad engineering.

> Demanding that my services always returned correct-looking data, even if it wasn’t available

Ah yes, the age old "special values will signal an error, so we don't have to deal with error handling" approach. Which is always either a pitch for reinventing error handling in novel and ad hoc ways (usually bad), or for disregarding error handling altogether (always bad, sometimes entertaining).

Spot on. Part of it is wanting errors-as-values without knowing what that is (which is good and contains a kernel of real insight), and part of it is assuming that error handling can be a negligible fraction of the work (which is the opposite of the truth and can only be achieved by doing a poor job of it.)

Reply on news.ycombinator.com