4 ms·

100% I used to be rather obsessed (can't think of a better term) and making my code performant but as I've gotten on in years in my career I've moved more towar

100% I used to be rather obsessed (can't think of a better term) and making my code performant but as I've gotten on in years in my career I've moved more towards "just ship it and don't break anything"

benrutter 3y ago
I 100% get this point of view, I don't really care about performance more than I need to to ensure stuff doesn't grind to a crawl but. . . I can't help but feel something has gone wrong in software where things are, by default, very slow. I've spent time optimizing code in the past (mostly python) and its not hard to speed things up a lot. It feels at times though that the ecosystem is working against you. Tools like electron encourage you to ship many many times more download size than is needed. Python loops speeds are getting better, but they've historically been insanely slow. I don't think we need to individually obsess over speed, but as an industry we need to give people the tools so that code is performing by default. I think we're moving away from that end.
- wredcoll 3y ago
  If you think electron's 500 megs is bad, wait until people start shipping LLMs that clock in at dozens of gigs.
  - fomine3 3y ago
    I don't blame how LLMs big, because it's needed for now. We theoretically don't need individual Electron runtime for each application. There should have a common webview runtime, like Microsoft WebView2.
norir 3y ago
As one develops as a programmer, the performance floor of your code should increase. In those early years, you might waste inordinate time squeezing out a 3% performance improvement in an existing feature when you could instead focus on building the next thing that might potentially double the product market. As long as you eventually see the light, I don't think this time is wasted because in chasing those small efficiencies you will learn the high level patterns that lead to good enough code as well as the evil of premature optimizations. Also, you will never get a bonus in proportion to the cost savings of an optimization.
- ajmurmann 3y ago
  > I don't think this time is wasted because in chasing those small efficiencies you will learn the high level patterns that lead to good enough code as well as the evil of premature optimizations. How many times in your career has a PM agreed to make room in the backlog to prioritize performance work? It very rarely happens and the reason is that costumers rarely care. It's catnip for developers and I love doing it, but it's rarely something that matters enough

benrutter 3y ago

I 100% get this point of view, I don't really care about performance more than I need to to ensure stuff doesn't grind to a crawl but. . . I can't help but feel something has gone wrong in software where things are, by default, very slow. I've spent time optimizing code in the past (mostly python) and its not hard to speed things up a lot. It feels at times though that the ecosystem is working against you. Tools like electron encourage you to ship many many times more download size than is needed. Python loops speeds are getting better, but they've historically been insanely slow. I don't think we need to individually obsess over speed, but as an industry we need to give people the tools so that code is performing by default. I think we're moving away from that end.

wredcoll 3y ago
If you think electron's 500 megs is bad, wait until people start shipping LLMs that clock in at dozens of gigs.
- fomine3 3y ago
  I don't blame how LLMs big, because it's needed for now. We theoretically don't need individual Electron runtime for each application. There should have a common webview runtime, like Microsoft WebView2.

norir 3y ago

As one develops as a programmer, the performance floor of your code should increase. In those early years, you might waste inordinate time squeezing out a 3% performance improvement in an existing feature when you could instead focus on building the next thing that might potentially double the product market. As long as you eventually see the light, I don't think this time is wasted because in chasing those small efficiencies you will learn the high level patterns that lead to good enough code as well as the evil of premature optimizations. Also, you will never get a bonus in proportion to the cost savings of an optimization.

ajmurmann 3y ago
> I don't think this time is wasted because in chasing those small efficiencies you will learn the high level patterns that lead to good enough code as well as the evil of premature optimizations. How many times in your career has a PM agreed to make room in the backlog to prioritize performance work? It very rarely happens and the reason is that costumers rarely care. It's catnip for developers and I love doing it, but it's rarely something that matters enough