alt Hacker NewsI'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.
Replies
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.
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.
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.
That person doesn’t sound like an A at all in my opinion.
Large corps value readability over algorithmic complexity too...
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.