[falsemyrmidon]

As someone that's a senior at a large corp, I absolutely do not want someone making the codebase more complex with the only benefit being being that it's now barely measurably faster. Especially when there are probably better things to be spending time on (spoiler, there are). Unless you're knocking like 20% off a very impactful metric, or addressing a looming scaling probably, go find something better to do than making tiny algorithm optimizations.

[Grimburger]

I've seen rewrites at startups that were slower and less stable than what we had before and everyone cheered it on like clapping seals. This stuff is rife no matter the size of the company.

At least at large orgs there's hopefully someone able to measure it. The smaller you go it's silos all the way down.

[caymanjim]

Agreed. Hardware is almost always cheaper than engineering time, until it isn't, and that's when you should spend the time on targeted optimizations.

[preg_match]

Typically this is backwards: simpler solutions often are more optimal, and complex solutions are not. Most code is slow because it’s just poorly written. If you write it simpler, then you can make it faster and easier to read. This isn’t always true, but it is true for 99% of the low hanging fruit optimization work that’s done in practice.

[cryo32]

Yeah good luck with that attitude over time. Most people don’t hang around in an org long enough to see that assumption scale to renting hardware than costs $900k a node a year.

[falsemyrmidon]

Seeing what you made get to the point that that's an issue is a "a good problem". Yes, it's worth it to optimize at that point, but that's still an argument for what I consider premature optimization.

[facundo_olano]

Most orgs never get to that scale

[gunalx]

The difference can also be from having builds over night to being able to build, test and deploy in a few minutes with just a few optimisations.

[lokar]

And as you approach that point you should have fleet wide profiling (sample based) so it’s clear what’s worth improving.

[nilirl]

I meant any institution where such cost of delay can be absorbed more easily. The cost of one day of that kind of work in a startup is probably more expensive than in a more established firm.