HN user

dtertman

132 karma
Posts2
Comments33
View on HN

Years ago I went to a BBQ cooking class run by the owner of a small, one-location restaurant in Chicago. He said that Sysco and US Foods reps called him every single day to talk about outsourcing his pulled pork and brisket to them.

This feels oddly similar, except there's only a couple Sysco's and US Foods' and probably thousands of AI Content Farm startups at this point.

I hate the weather where I live (Chicagoland), so I spent a week a couple years ago downloading weather data from WUnderground and geo data from a bunch of places and turning it into a reverse weather index - instead of searching by place, you'd search by weather.

I found the best weather for me was in Antofagasta, Chile, but I never did anything with this knowledge :)

Unfortunately it was all built on an OpenShift gear on the free tier, so it's dead now.

Redis explained 4 years ago

At desktop resolution, the floating table of contents menu blocks out two of the (excellent) illustrations (second and second-last). Deleting aside.toc was very helpful.

The idea described here is implemented in e.g. TikTok's API, and as a consumer of that API (in Java at least), it has been awful to code against.

Because most people abuse status codes, most tooling is built around status codes. All of the Java HTTP libraries, for instance, throw very nice and easily-handle-able exceptions for non-200 status codes, but do nothing at all for 200 codes. So, now, we need to:

* try/catch the call anyway, because it might fail * parse the result * figure out if the result is an error or OK * throw / return early from error results * separate that throw from the try above

It's all so much hassle to avoid a mistake that _client libraries don't make_ : using the wrong URL in the first place.

(if the covid effect is persistent for a year)

I think that's the important bit. The article (at least) didn't indicate that the same standard applies at the 180, 270, or 360 day mark, so I don't think we can just say COVID patients roll the dice on mental illness 4x as often as the general population. If that's actually being implied, it's horrible.

The Red Apple, quoted in the story, closed their original location (that had been open for 30 years) last summer to make way for condos. At 5% margins it's pretty easy to see how a builder could make them a great or even life-changing offer.

Thanks, I hate it. My most recent update of IntelliJ turned this font on by default and I had to spend an hour trying to figure out what the font used to be.

Mono looked squished to me - the intentional favoring of length over width made the whole editor look like I had an aspect ratio problem on my monitor. I appreciate trying to push the envelope and improve ergonomics, but I wish this would have been opt-in for upgraders.

That it is very important to communicate the strength of an opinion, and moreso the higher up in an organization you go.

If you say everything like a Gospel truth, even when you're just brainstorming, the two end-states I've found are constant argument or constant acquiescence, and neither one is healthy for collaboration.

Conversely, if you always hedge your opinions, even ones that are against your moral code, you may end up unhappy, doing some unsavory stuff, etc.

A book that goes through this in detail is "Opening Doors To Teamwork and Collaboration". They have a very jargon-heavy approach to it ("notion", "stake", "boulder", "tombstone"), which I don't agree with, but the concept is important.

If you are tracking the impersonation correctly it should be easy to see internally that the user didn't change the address or request a 401k loan themselves and a system should be in place to ensure that such changes get flagged and reviewed.

Inbound voice is notoriously difficult to establish metrics on. You generally have to review the calls. The HRO company has (literally) millions of participants, and so keeping up with the call volume from all of them is a challenge.

when the user is not aware of the impersonation

I'm curious, so please don't assume ill intent. What's a valid use-case where an event would be 1) done by an impersonator, 2) not driven by the person being impersonated, and 3) produce a notification that should be squelched?

Your three use cases don't seem to lead me to those situations: In the first one, you agree that notifications are OK. I agree with that.

In the second one, it's read-only, and so I wouldn't expect notifications to be produced. If there are notifications about read-only aspects (your account was accessed, e.g.), I suppose I'd be OK with them being suppressed, but I think I'd still lean towards a custom notification (your account was accessed by an administrator, e.g.).

In the third one, shouldn't you scrub your data while you dump it? Everywhere I've ever worked that didn't scrub their data (i.e. set all of the email addresses to nobody@testingmystuff.com) eventually regretted it.

if possible, disable user notifications/emails when an account is being impersonated — or remind staff that impersonating a user will still generate emails, notifications, and dashboard events.

Never, ever disable notifications. Notifications are the only way the user has to cross-check that the agent actually did the thing they were supposed to do, and only that thing.

I worked for a large benefits outsourcing corporation. We had impersonation, and we had a way for agents to cancel notification. A few agents realized they could change a participant address, get a 401k loan, and then cancel the notifications for those things. They used these combined capabilities to steal from our participants.

Here's the right calling for a boycott of Starbucks because they had the gall to say they would hire refugees: https://www.washingtonpost.com/news/food/wp/2017/01/30/starb...

Here's the right calling for a boycott of GrubHub, Pepsi, Oreos, and Netflix over slights to Trump: https://thinkprogress.org/trump-pepsi-grubhub-boycotts-ca810...

These are five examples since November. There are thousands. Both sides are equally childish.