5 ms·
The outrage around these supposedly egregious performance issues is more understandable when you consider that developers who spend a lot of time tuning perform
by westoncb 5y ago
The outrage around these supposedly egregious performance issues is more understandable when you consider that developers who spend a lot of time tuning performance in their work would naturally develop a 'selective attention bias,' magnifying the significance of what to others are negligible if not imperceptible differences.
Imagine the frustration of someone who, for example, did work on sound insulation for cooling systems: they sit out on a patio for dinner with friends and the sound of an inexpertly designed air conditioner appears to them as intolerably intrusive; meanwhile, no one else at the meal notices until it's pointed out.
- runawaybottle 5y agoThe imperceptible becomes perceptible when you make it noticeably more perceptible. A better point would be to not even show the user what they are missing out on, because then that will be the standard. The danger of the latter is it is very likely your competitor(s) will show it to users anyway. I’d let the guy that tinkers on performance keep tinkering.
- SilverRed 5y agoNone of the competitors care about making the ui 20ms faster. Apple music just flat out didn't work for me, totally broken for the web version and not even an electron app. Spotify is already better than the alternatives.
- westoncb 5y agoAbsolutely. Anyone building on top of performance critical systems should have a healthy bit of gratitude for the engineers who were interested to specialize there. That said, I think it's good to remain as objective as possible about the actual impact of optimizing for performance in different domains. So for instance, the impact of attention paid to performance in the codecs used by a music/video player, or the v8 runtime, or rendering or networking subsystems in e.g. macOS or Chromium is huge. However, should we expect the impact of optimizing to be similar in application-level code for consumer apps? I would argue no (granting that exceptions exist). At this layer the computations are for business and display logic, and calling into highly performant subsystems. Additionally, they are typically 'leaves,' not dependencies of other systems (which would cause their performance choices to ramify). This is not to say consumer apps are able to ignore performance concerns: you can still make garbage that way. But you'd be deep into the region of diminishing returns if you poured as many resources into performance for application-level code on something like Spotify as you did on e.g. codecs it uses or low-level rendering code it depends on. And that's the reason tech like Electron is so often selected by folks whose bottom line is massively affective by their ability to be objective about these issues.
- TeMPOraL 5y agoThere's a huge difference in the performance levels you're talking about, which creates a risk of unintentional equivocation. I've written long rants about this in the past, so let me draw a picture instead: codecs, chrome old spotify slack, teams, renderer | current spotify | | | |--v----------v----x----------v--------| FAST | SLOW slow enough to notice during casual use \________/\________/\________/\________/ | | | | overkill | bad UX | | you're just being good UX mean to users (your app should be here)
- westoncb 5y agoA couple things here. First is that this is fundamentally a question of tradeoffs, which means a single axis diagram like this is fundamentally misleading. For instance, we have the conclusion about 'being mean to users' toward the slow end of the scale. But if the tradeoff means the app costs more, or has fewer accessibility or language features, or doesn't run on the user's chosen OS—which is more mean? Second, this topic is contentious not because Spotify is slow but because many readers believe that building on Electron implies your app will be slow and is a basically negligent technology decision, a blight on the field of software engineering, and so on and so on... So, while I agree with your placement of Teams (though not Spotify incidentally), saying that because a couple Electron apps are not optimally snappy in this context reinforces the (imo) mistaken attribution of non-snappiness to Electron: afaict, of the major Electron apps out, there are at least as many that are snappy, and of the ones somewhat lacking in this department there are no native apps with feature parity to compare against (i.e. for Slack or Teams; Spotify otoh, maybe it is really bad for some people—not my experience, and the sample of 1 wouldn't prove much). In any case, I like the diagram and largely agree with its assertions in isolation. Edit: I'd be happy to take a look at one of your longer rants if you want to point me to one. I am genuinely interested in better understanding the situation if I've missed something.
- 5y ago
- blub 5y agoJudging by the dismissals of performance concerns seen in typical online discussion threads, I'm not sure that developers working on performance tuning in any meaningful way still post online. On the contrary, I have the impression that people snubbing performance while claiming that user satisfaction or business goals are the only things that matter do not care about performance or dare I say technical brilliance at all.
- westoncb 5y ago> I'm not sure that developers working on performance tuning in any meaningful way still post online This is a very confusing comment to me since "cares a lot about performance" is probably one of the most consistent attributes of the HN readership—or they are at least a highly vocal subset of the community. Personally, I respect technical brilliance, but believe it comes in many varieties, of which performance tuning is just one and not on any kind of higher plane.
- Cederfjard 5y agoIn terms of running a business, surely user satisfaction and business goals are much more directly relevant than performance in and of itself, except insofar it contributes to the former? So it's not surprising to me that you'd see a lot of that sentiment on a forum hosted by a startup accelerator, nor that it's what for-profit organizations optimize for. That doesn't mean that people can't also have an appreciation for well-performing or technically brilliant code.
- yomly 5y agoI'm starting to come to the conclusion that performance is much more important than we realise. This thread is about how Spotify seemed like magic in the early days. The original iPhone seemed like magic. Netflix seems like magic in how fast it can stream. Similarly, early google and amazon were always fast. I believe our subconscious values speed as an indication of quality far more than our product owners know how to measure for.
- dimmke 5y agoI can only share my experience. I used Spotify for the first time in 2011. It completely defied what I thought was possible with music streaming. Songs would play immediately. It was faster than iTunes. I believe Spotify is still faster than Apple Music. This was at a time when I had no expectation that my smartphone's internet was fast enough to do much of anything. It was so impressive, that I became a paying customer and have been a paying Spotify customer for 10 years. And Spotify pulls a lot of annoying bullshit. They have a habit of treating their users like shit in various ways - you pay and don't get ads in between songs, but they still spam pop ups and try to direct your behavior in various ways. It feels like their attitude towards you as a user is very much influenced by the "free tier" even if you're a paying customer. Their various app UIs have suffered greatly over the years (current incarnation is mostly tolerable) But the base thing they do - play music faster than any other service is what has kept me. I also don't think it is ethical that Apple can offer a competing service, while forcing Spotify to give up a significant cut of its revenue. I think it should be illegal, so I likely would never pay for Apple Music because of that.