Live data from Hacker News

Fast

catherinejue.com

41–50 of 450 posts

Re: Fast

#41
> Instant settle felt surprising in a world where bank transfers usually take days.

Yeah, that's not "a world" it's just the USA. Parts of the world - EU, UK etc have already moved on from that. Don't assume that the USA is leading edge in all things.

Re: Fast

#42

This is one of the reasons I switched from Unity to Godot. There is something about Godot loading fast and compiling fast that makes it so much more immersive to spend hours chugging away at your projects for.

My son told me to not develop a game with Unity because, as a player, he thought Unity games took way too long to load.

Re: Fast

#43
I've noticed over and over again at various jobs that people underestimate the benefit of speed, because they imagine doing the same workflow faster rather than doing a different workflow.

For example, if you're running experiments in one big batch overnight, making that faster doesn't seem very helpful. But with a big enough improvement, you can now run several batches of experiments during the day, which is much more productive.

Re: Fast

#44

> Rarely in software does anyone ask for “fast.” Are you kidding me? My product owner and management ask me all the time to implement features "fast".

Not sure if this is sardonic obstinance... But assuming face-value - that's not what the statement is about. I disagree with the statement too, as people definitely ask for UX / products to be "snappy", but this isn't about speed of development.

These days metrics are so ubiquitous that many internal back-end systems have SLAs for tail latencies as well.

Re: Fast

#45
Agree. One of my favorite tropes to product and leadership is that “performance is a feature”.

Re: Fast

#46

I think that people generally underestimate what even small increases in the interaction time between human and machine cost. Interacting with sluggish software is exhausting, clicking a button and being left uncertain whether it did anything is tedious and software being fast is something you can feel. Windows is the worst offender here, the entire desktop is sluggish even though it there is no computational task wh…

There's that wondering if the UI input was registered at all and the mental effort to suppress clicking again when you expect a delayed response.

Re: Fast

#47

Only sorta related, but it’s crazy that to me how much our standards have dropped for speed/responsiveness in some areas. I used to play games on N64 with three friends. I didn’t even have a concept of input lag back then. Control inputs were just instantly respected by the game. Meanwhile today, if I want to play rocket league with three friends on my Xbox series S (the latest gen, but the less powerful version), I…

That may be an issue of going from a CRT tv to an LCD tv. As far as I am aware there was no software manipulation of the video input on a CRT. It just took the input and displayed it on the screen in the only way it could. Newer tvs have all kinds of settings to alter the video which takes processing time. They also typically have a game mode to turn off as much of it as it will allow.

Why should the user care whether the lag is introduced by the software in the controller, or the software in the gaming console, or the software in the tv.

The lag is due to some software. So the problem is with how software engineering as a field functions.

Re: Fast

#48

> Rarely in software does anyone ask for “fast.” We ask for features, we ask for volume discounts, we ask for the next data integration. We never think to ask for fast. Almost everywhere I’ve worked, user-facing speed has been one of the highest priorities. From the smallest boring startup to the multi billion dollar company. At companies that had us target metrics, speed and latency was always a metric. I don’t thin…

My experience has been that people sometimes obsess over speed for things like how fast a search result returns but not over things like how fast a page renders or how many bites we send the user.

Re: Fast

#49
Efficient code is also environmentally friendly.

First, efficient code is going to use less electricity, and thus, fewer resources will need to be consumed.

Second, efficient code means you don't need to be constantly upgrading your hardware.

Re: Fast

#50
post #20

Pavel Durov (founder of Telegram) totally nailed this concept. He pays special attention to the speed of application. The Russian social network VK worked blazingly fast. The same is about Telegram. I always noticed it but not many people verbalized it explicitly. But I am pretty sure that people realize it subconsciously and it affects user behaviour metrics positively.

Telegram is pretty slow, both the web interface and the Android app. For example, reactions to a message always take a long time to load (both when leaving one, and when looking at one). Just give me emoji, I don't need your animated emoji!
Post reply on HN