Hacker News Reader

Comment by questionableans | Hacker News Reader

It’s all about being balanced and picking the right strategy for the situation, not doing everything all at once. A guide like this could be useful for someone to consult when they find themselves in a different situation, regardless of their seniority level.

And in my experience, more senior engineers don’t have a greater risk of being fired for a project going badly because they identify problems to work on that matter and are within their areas of expertise, and evaluate possible risks early and communicate them.

View on HN

Being balanced about political/soft skills makes me nervous, especially when it becomes a mandate and your main role. Some people are good at it, some are bad -- but it's completely irrational to expect this to be the logical next step for ICs and senior engineers.

I've seen it backfire spectacularly when a very senior engineer who worked in a critical part of the product was forced into this "because of promotions", then because he was an introvert did it poorly and got a really bad performance review ("underperformer"), got upset and quit. Aftermath: his manager ended up getting fired because of this screwup, but truly that was scapegoating. What's worse is he was happy in his previous role, doing groundbreaking work, didn't want the promotion and wasn't planning on leaving.

I'm not disputing what you say, but in my experience the middle technical roles are the safest. Too junior and you'll be the first to be axed for mediocre performance, too senior and you'll be blamed for failures and fired (sometimes for playing the political game and losing). Meanwhile, the mid/senior programmers doing the work will keep on.

Unless there's another round of layoffs, those upset everything.

That’s why a lot of companies only promote after demonstrating a track record of performing at the next level.

It can also be an argument for secret levels. Although I’m not sure how useful that really is in practice.

For someone who does well at influence, it’s not a mandate, it’s permission to spend some time on the nontechnical factors that are necessary to make your work turn out better. And that also means helping others who have good ideas but aren’t comfortable with the influence part themselves.

> 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.

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.

Reply on news.ycombinator.com