Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

eugeneyan.com

Post reply on HN
Print view View original

141–150 of 163 posts

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

#141

Post by the_af »

questionableans wrote: post #138
the_af wrote: post #132

Earlier quoted context omitted.

> That’s why a lot of companies only promote after demonstrating a track record of performing at the next level. If that's the case, why is this article needed? Someone promoted to Principal is already savvy, why would they benefit from this advice?

Why does an experienced programmer ever need to look anything up? It’s useful to have reference materials to check against, or for things you haven’t worked in recently.

I don't think this is like looking up a reference. This article is a general guideline on how to be a good Principal IC, the thing you're supposed to already know if you're a Principal IC.

This is like reminding a top doctor "do differential diagnosis". Nope, top doctors already know this, it's redundant advice.

This is like reminding a good thinker they must think about things: they already know this and it's presumably how they got to the position in the first place.

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

#142

Post by the_af »

mattgreenrocks wrote: post #121
the_af wrote: post #37

To me, in a way, it reads like Principal IC is the worst possible job. You're doing all the politicking and influencing stuff many of us presumably don't like and associate with management roles, while also being expected to be "hands on" and at the top of your technical game. "Nothing is not part of your job", as this article describes it. Someone who's not doing this, the article argues, "is setting themselves up f…

There’s a reason burnout rates go up at staff+ levels. Expectations go up w/o a commensurate amount of managerial control.

Yeah, that's my feeling as well. I'm not a Principal but I've seen people promoted to the position burn out.

I'm content being in a senior engineering role where I still get to do technical stuff (and yes, some mentorship as well). Then again, I don't define my life by my career, I'm OK with doing interesting stuff and earning a decent paycheck without climbing up the ladder. Alas! Eventually I will age out of this possibility. I'm already dreading it.

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

#143

Post by the_af »

cvwright wrote: post #109
the_af wrote: post #39

Earlier quoted context omitted.

The way the author describes it (in contradicting terms; see the point where he claims if you're a Principal IC, you were promoted because you already acted like one, making the ~30 items of advice redundant) it's the most stressful position ever. Be critical, don't be in the critical path, be laid back in an advisory role but be hands-on or you're setting yourself up for failure, work on stuff you enjoy but be ready…

The contradictions are difficult but wisdom has always been like that. See for example the book of Proverbs, it’s full of contradictory advice. “Do not answer a fool according to his folly, lest you also be like him.” Versus “Answer a fool according to his folly, lest he be wise in his own eyes.” The skill is to understand the truth of both statements, and to discern when to apply each one.

I'm not sold on that kind of wisdom, it's very close to empty platitudes.

Atheist here, so Bible wisdom is especially not useful to me.

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

#144

Post by srnayak »

akdev1l wrote: post #112
brown9-2 wrote: post #96

Earlier quoted context omitted.

Amazon skipping “staff” and jumping straight to “principal” seems like such title inflation

on the contrary it seems like title deflation as Amazon principal engineers typically work at a higher level than staff at most other orgs (at least I remember a Microsoft principal would be basically an Amazon L5-6 level)

Amazon L5 is SDE2. I am not sure how you can equate a Microsoft Principal to Amazon L5. Getting to L6 in Amazon is very easy these days due to title inflation. Managers also know how to rig the system to gather the data points for promotion. There was a time when Amazon promotion bar was high and Amazon SDE3 were considered same as Microsoft Principal. But things have changed now. A fresher needs only 2 promotions to get to L6. Some are getting there in 2-3 years. So Amazon L6 does not have the value that it used to have a decade ago. At Microsoft a fresher will need 6 promotions to reach Principal level. People are reaching principal levels early, but not in 2 years.

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

#145

Post by disgruntledphd2 »

questionableans wrote: post #123
disgruntledphd2 wrote: post #54

Earlier quoted context omitted.

> To me, in a way, it reads like Principal IC is the worst possible job. It depends on the person, I think. Personally, I often end up doing this sort of work, particularly in smaller companies. I really like it, but appreciate that the vast, vast majority of people I work with would hate it. For some people, they prefer to lead through influence, rather than through a reporting line. There's a lot of toil in managin…

Not only that, but leading through a reporting line is 90% influence, too. Relying on pulling rank will get your best reports to find a way to leave ASAP, and others will follow.

That's true, but it's still different with Principal roles as you can't get budget or headcount of your own.

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

#146

Post by imiric »

questionableans wrote: post #124
LPisGood wrote: post #56

Earlier quoted context omitted.

Making your whole living on influence without authority sounds awful.

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 people who are held in high regard for whatever reason certainly have more authority, and thus influence, to enforce their will over others. Reviews of their code often have a single "LGTM!", or they might even merge without approval.

Similar situations happen outside of software development as well. A highly charismatic person in a friend group has more influence, even though everyone is aiming for the same goal ("get dinner", etc.). An opinion from popular people on tech forums like this one carries more weight than an opinion from someone unknown, even if it's the same opinion. And so on.

So coming back to "principal" ICs in companies, these are mostly political rather than technical roles. The person got to that position because they proved their ability to be influential and lead teams, which generated increased revenue for the company. The company is betting that putting them in a position with more authority, where executives lean on them directly, would lead to even greater revenues.

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

#147

Post by imiric »

questionableans wrote: post #139
the_af wrote: post #131

Earlier quoted context omitted.

Yes, but the stakes at your job are different. You don't get fired or get bad performance reviews if you fail to convince your friends to go out for dinner. You're not expected to be constantly be doing this either. You are not paid a top salary and get performance reviews based on that. Principal ICs sounds like a high stress occupation...

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 working knowledge of each area, have the ability to jump in and steer each ship—whether that involves communicating with each team, removing roadblocks, or writing code themselves—, and be able to communicate all of this in a language useful to executives.

When individual teams are not working well, when multiple teams are not working well together, and ultimately when value is not being produced, it is people in these roles who will be on the hook first.

So the stakes are indeed much higher for this role than for someone working in a single team.

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

#148

Post by imiric »

the_af wrote: post #141
questionableans wrote: post #138

Earlier quoted context omitted.

Why does an experienced programmer ever need to look anything up? It’s useful to have reference materials to check against, or for things you haven’t worked in recently.

I don't think this is like looking up a reference. This article is a general guideline on how to be a good Principal IC, the thing you're supposed to already know if you're a Principal IC. This is like reminding a top doctor "do differential diagnosis". Nope, top doctors already know this, it's redundant advice. This is like reminding a good thinker they must think about things: they already know this and it's presum…

That's a good point.

I think this article is a promotional piece for the author's personal brand, thinly veiled as advice for others. It's "look at what I know, and here's why you should pay me". These people love to talk about themselves.

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

#149

Post by rixed »

questionableans wrote: post #122
rixed wrote: post #110

Earlier quoted context omitted.

Sure! You mean writing documentation, aligning divs, writing tests, caring for the infrastructure, right?

If it’s important and it’s not getting done, yes. Let’s take aligning divs. What’s the real problem here? The front end looks really bad and it’s causing us to lose potential customers. Why is that? Maybe we have a shortage of frontend devs. Maybe the frontend code is a mess and people are just hacking in small changes here and there to minimize the time they spend with it. (Maybe both.) What do you do about it? Fix…

> That’s principal level aligning divs.

Should be added to "The Evolution of a Programmer"[0]

[0] https://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer...

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

#150

Post by the_af »

mattgreenrocks wrote: post #85
dwb wrote: post #42

Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is , as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

I'd argue not every engineer is necessarily cut out for staff-level positions and responsibilities. I've always felt staff+ was a bit of a trojan horse on the IC ladder. I understand the role and its importance to be closer to the work. But some companies really seem to love separating you from the work to be done in pursuit of the almighty iMpAcT. I have seen extremely talented engineers not get their promo to this…

> then witness the org retcon their judgment into a staff-level promotion without any significant change in duties.

Isn't this good for the engineer, though? Presumably they are good at what they do because they like it. So they get a nice promotion and a raise without a change of duties, so everybody wins.

Why promote them out of their skill set, and possibly into a role they will hate and get them fired or willing to quit?

Post reply on HN