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 2 hours ago | parent | next [-]

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 an hour ago | parent | next [-]

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 an hour ago | parent | prev [-]

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.

	▲	cryo32 an hour ago \| parent [-]
		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.

▲

renegade-otter 4 hours ago | parent | prev | next [-]

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 3 hours ago | parent [-]

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)

	▲	an hour ago \| parent [-]
		[deleted]

▲

chrismcb 3 hours ago | parent | prev | next [-]

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.

▲

LPisGood 2 hours ago | parent | prev | next [-]

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

▲

throwaway314155 3 hours ago | parent | prev [-]

Large corps value readability over algorithmic complexity too...