Hacker News new | past | comments | ask | show | jobs | submit login

This is really well said.

Part of problem finding is also taking vague inputs "that subsystem is kinda wonky" and transforming it into "that system has these specific problems, which can be fixed with this approach, which will take roughly this long, and help out this much".

The existing group may not have made tickets for something because they think "it'll take six months" or "we'll have to change x,y and z before that idea is gonna help us", because they don't have the time to analyze a known pain point for how painful it is, or even because they haven't thought of the improvement. Then someone realizes that those assumptions are wrong, and finds a big improvement.




If it doesn’t solve a problem the existing team already acknowledged, or at least very directly accelerate the fix for one of those problems, that doesn’t sound like a good outcome from a new hire to me.


I can't decide whether to agree with you or not. On the one hand, I think a lot of the changes I'm talking about changes that should accelerate the fix for problems you have (what team doesn't think "it's too hard to work with x" at some point?).

On the other hand, I feel like you're coming at this from the perspective that your existing team is omniscient, or at least always knows better than someone new. We used to have that dynamic, and I think it's better that we're now more open to new ideas (onboarding is still way slower than I'd like, but it's improved).


Current team certainly isn’t omniscient. Just that you’re liable to make enemies, not friends/develop career, by coming in and proposing brand new, undesired/unforeseen changes and winning the argument with management.

Brand new not-desired-by-team features/changes often end up owned and maintained by the existing team for a long time, often long after you’re gone. You, as a new person, probably aren’t shouldering much maintenance burden yet, bad to be perceived as adding more rather than reducing load.

Much better to fix a generally acknowledged problem, reducing maintenance burden for the existing team.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: