3 ms·
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 ba
by falsemyrmidon 4mo ago
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 4mo agoI'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 4mo agoAgreed. Hardware is almost always cheaper than engineering time, until it isn't, and that's when you should spend the time on targeted optimizations.
- cryo32 4mo agoYeah 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.
- facundo_olano 4mo agoMost orgs never get to that scale
- falsemyrmidon 4mo agoSeeing 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.
- preg_match 4mo agoTypically 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.
- deleted 4mo ago[deleted]
- nilirl 4mo agoI 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.