Yeah this smells like the type of comment an LLM leaves when it gets a really specific instruction. “use one consistent color for the data timeline. Right now we’re using multiple which is confusing.” Then the LLM writes some comment that’s a mini retrospective on what happened to justify itself.

Also “the clock at the top is exact” but the clock (on my phone, at least) is at the bottom. Still cool though!

"mic-droppy" is the perfect description. Now I can imagine Claude sheepishly picking up the mic yet again after I correct it.

I learned three thresholds over the years. Well, one of them decades ago and the others recently. Basically:

At 50ms, you notice.

At 400ms, you care.

At 2000ms, without output, you wonder if it crashed. (That was the old one.)

I was expecting the site it’s talking about to have faked an instant response. Ironically, sometimes it goes the other way and UIs have to fake a small delay otherwise the user won’t believe it’s actually done anything (although arguably the real issue there is lack of positive feedback, not response time.)

I’ve definitely had in the UX side a situation where the PM/Owner types asked me to introduce a delay in the “disabled button with loading spinner” such that the user sees it for a visible amount of time because our API was too fast for their taste.

I don’t think a visa transaction can go faster than about a half second so definitely something off there.

It only inserts a sku and a quantity into a Postgres database - yeah, there’s a few things missing from this purchase scenario.

Might have been better to have made it clicking a ‘like’ button.

Same, I call it the perception of work.

Your comment reminded me of when Google introduced "Instant Search" in 2010. Here's an old HN thread from the launch: https://news.ycombinator.com/item?id=1672391

IIRC TurboTax has a bunch of loaders / spinners like this, similar idea.

You are not jealous. You are envious.

Homer explains it best https://youtu.be/Tmx1jpqv3RA

I once asked a question like this for an interview. "Tell me what happens when you press the Buy button on a web site". It really helped me gauge a sense for the person's interests and expertise. Like some folks just talked about javascript and some node code. Others talked about tcp a bit, some got into cloud stuff. It was really telling. Not bad or good, just a great way to learn where someone's head is at and was a fun back-and-forth conversation.

This web site is basically a cheat code for that question lol. So well done, kudos to the author. Bookmarked and shared

While I also enjoyed it very much, some thing are strangely ordered and not how I would expect someone with such knowledge of all the moving parts in a request, would build such a site. So for me it feels like an LLM has build it and the human with the prompt saw it and said "eh, good enough".

Usually the dominant time is from POS to acceptor. These are frequently still on high latency links.

Also a lot of times in person payment flows allow a lot more in their latency budget because it won’t impact the sale, you won’t walk out because of a second here or there, unlike online.

So systems aren’t as optimized, they route to older systems, marketing or further risk checks are added, and a broader range of accepted services that have higher latency (ent/snap processors and the like).

This scenario does not include payment. Would be much more interesting if it did.

I’ve always wanted a version of this sort of a timeline that really lets you zoom out and in to the fractal complexity of it all. Right at the end we’re talking about updating the DOM and rendering… there’s a whole Unicode and font stack and rasterization process happening in there.

I once got that question, started with the keyboard switches and the interrupts, and the interviewer sighed and asked me to get to the stuff in the browser.

I still like this question because of exactly what you mentioned. What the interviewee does and does not mention can give you a fair bit of insight into their priors.

The US is so big, that 50 ms is physically not possible for everyone. This is something that not everybody is aware of. When I as a German build something for germans, everyone who needs to wait longer than 100 ms for a request, is rightfully mad. But when I want to serve the same stuff to americans at the same speed, I have to build something completely different and much more complex.