[nilirl]

I've met maybe 1-2 people in my whole life who were clearly beneficial 'A' from the get go. There's also a weird 'A' that tries very hard but causes more pain than inspiration. Meaning, they're clearly smart but think that's all that's necessary to be useful.

I once worked with an intern from MIT who came in and immediately submitted large PRs everyday that improved the algorithmic complexity for a bunch of functions. Which was awesome to see but the changes were off the hot path and the code was much harder to read. The part that still comes to me was when I'd said during a code review that there were other more pressing concerns, the intern said yes but you can't argue against the improvement in time complexity.

Smart guy. Inspirational, even. But better suited to a large corp than a startup. I think a startup 'A' has a lot more to do with attitude about speed and uncertainty than competence.

[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.

[renegade-otter]

Related, but the best quality to have in a startup is knowing when and what corners to cut instead of going on these side quests.

[apsurd]

I used to think this but you only know which were the right corners to cut after the fact. And most things are not obviously right or obviously wrong, instead it’s a slow zombie death by a thousand fuzzy signals.

And the management tier of the startup will too easily color the signal by the flavor they want to see.

My latest take on this matter is to separate speed as in fast from quick. Quick is the thing you want and almost always good. Fast is what usually gets lauded and measured but fast just gets you large volumes of fuzzy signal faster.

(quick means that something can take time and be measured, not rushed, things can bake, and the feedback loop is responsive quickly throughout the loop. while fast is looking at wall clock time and goaling on the end-result yield from the loop. i think it’s very misguided. things very often need bake time)

[lokar]

And sometimes the yak shaving side quest yields big improvements that were not even on the radar.

Good engineering intuition, the ability to learn new code/systems quickly and the ability to quickly validate ideas is extremely valuable.

[renegade-otter]

Yes, but it does get easier with experience and some battle scars. Telling a startup to stick to the problem and not go wild with microservices and event sourcing is not exactly a hot take.

[cucumber3732842]

Which is exactly why you need people who have a good gut feel for such things.

[spockz]

I think there is nothing inherently wrong with changing code that can be improved but shouldn’t have focus as long as the other work also happens. It improves his understanding of the codebase and makes the code “better”. (Obviously, feedback needs to be taken into account.)

I can think of two reasons why he worked that way:

1. It was unclear exactly what he should be focussing on. Were there tasks/tickets describing what needed to be done? Or was it just a vague “fix this”. Doing peephole, local changes to code are easier and improve understanding of the whole. 2. In addition to working on the main tasks, I tend to fiddle around with other code while the main problem is percolating in my brain. Somehow working on other problems helps me solve my main problem faster than just focussing on the main goal.

[chrismcb]

Yeah, I can argue against it. How much time did he spend on it, how much is games on the user the (as in, is this a common use path or an uncommon one) you may have doubled the speed but did it go from several seconds to a few, it a split second to a half split second? Are there other things that should be implemented before speeding things up. Etc etc.

[throwaway314155]

Large corps value readability over algorithmic complexity too...

[LPisGood]

That person doesn’t sound like an A at all in my opinion.

[nilirl]

Relative to my technical skills.

One of the PRs was some data visualization code in the Elm language. They explained the solution so beautifully, showing how the problem lay in how the Elm compiler compiled to JS and how JS managed memory. It just blew me away that this person did this in an evening, with no experience in Elm or front-end developement, and that it would've taken me days to be that precise. And they weren't even out of college yet.

Edit: This was pre-LLM, where research and reading were a big part of the job

[tremon]

> you can't argue against the improvement in time complexity

No, there's absolutely valid arguments to be had over asymptotic complexity when the you know the relevant bounds of the dataset.