Live data from Hacker News

Advice for new principal tech ICs (i.e., notes to myself)

eugeneyan.com

161–163 of 163 posts

Re: Advice for new principal tech ICs (i.e., notes to myself)

#161
post #146

Earlier quoted context omitted.

That’s life. Unless you’re a hermit, a complete pushover, or a slave master, you’re constantly trying to influence without authority. Want to go out to dinner with friends? That’s influence without authority right there. Want to get your PR approved? Influence without authority. Trying to get your point across to strangers online? Ditto.

> Want to get your PR approved? Influence without authority. That's not really the case. First of all, software development is—or should be—a collaborative effort. The PRs I create are no more "mine" than the ones I review from my peers. We're all working towards the same goal, and developers shouldn't have to defend or vouch for their work. Secondly, politics plays a role in every organization, unfortunately IMO. So…

Authoring and reviewing PRs when no one person owns them individually sure sounds like influencing the direction of the team without any authority to make a unilateral decision to me.

You’re right about politics, but I think the part where people may vary is the definition of authority. Does being consistently influential make someone an authority? It depends on what that means. They will be believed more often (they have soft power) but they don’t have hard power to command someone to do something. What makes it a gray area is they almost surely have influence with someone else who does have hard power.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#162
post #147

Earlier quoted context omitted.

I’m sure the stress level varies by the individual. The upside to a more collaborative role like this is you don’t have the stress of having to know everything. Individual developer roles can be more stressful because if you say you’ll solve a problem in a certain amount of time, and then you’re off on your own coding, and things aren’t working out… you’re personally on the hook for the whole thing. Whereas if you’re…

You're painting a very rosy picture of what this role entails. > The upside to a more collaborative role like this is you don’t have the stress of having to know everything. It's the opposite, actually. The person in these roles has to wear many hats, and have an overview of many areas and teams in the company. The article is explicit about this. They may not be an expert at everything, but they should certainly have…

It’s different for different people, but IMO, knowing something significant about everything is easier than knowing everything about something significant.

And if you understand the organizational dynamics, being in a position to fix (or recommend the cancellation of) projects that aren’t working gives you more control over your destiny than being just another person trapped in a dysfunctional org.

So I’m not saying higher level roles are easier for everyone, but I am saying lower level roles can actually be harder for someone who has mastered higher level roles.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#163

Earlier quoted context omitted.

>Who is taking “because I said so” as a (first) reason to make an engineering decision with no justification? Justifications, needing to say things, etc., are for the weak. The strong get away with shit. That's how you know they're strong! Or at least that's what >50% of the people I've met throughout my life consider normal. Maddeningly, heartbreakingly, infuriatingly, that number seems even higher among computer pr…

We have no widely accepted metrics for code quality, so almost everything in software beyond “does it work” is subjective. It’s opinions and taste all the way down. If you ask why the vast majority of people have no answer other than “because I like it that way”.

>“because I like it that way”

That'd be refreshingly honest.

Post reply on HN