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

On Being a Principal Engineer

blog.dbsmasher.com

Post reply on HN
Print view View original

301–310 of 337 posts

Re: On Being a Principal Engineer

#301

Post by bluGill »

ryandrake wrote: post #290
2muchcoffeeman wrote: post #144

Earlier quoted context omitted.

> It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’. As you said, good outcomes are team efforts. Even your best developer is not going to do anything great if he’s fixing bugs. Less senior d…

> Even your best developer is not going to do anything great if he’s fixing bugs. Honestly, I wish this mentality would go away. Maybe software in general is so "barely shippable" shitty because 95% of everyone's engineering effort is spent on cranking out features rather than fixing bugs and improving stability/performance. Somehow, feature work is glamorous and gets you promoted and quality is seen as boring, dead-…

The best developers are the ones you can give the hardest bugs to and trust they get them done. The ones where the principal engineers see someone heading for your desk and jumps up to figure out why - stopping your interruptions is far more important than anything else! (You can't give these to the principal engineer because his job is to be interrupted)

Re: On Being a Principal Engineer

#302

Post by erichurkman »

scarface74 wrote: post #151
valleyjo wrote: post #90

Earlier quoted context omitted.

I’ve seen this happen even within the same (large) company. Someone is a director level who has maybe 100 reports. The entire product gets cut. The IC’a find other jobs within the company. There are only so many Director level positions around and many of them are achieved organically. The ex-director then goes somewhere else as a regular engineering manager unlikely to ever have such a position again.

Three of my former managers “self demoted” to an IC because they didn’t really enjoy management. Including one of my former managers who is in his late 50s who self demoted after his kids graduated. Now he’s a full stack React/C#/Azure developer and said he threatened to quit his job when they tried to promote him.

You need a path of self-demotion otherwise the only route to fixing a misplaced promotion is by firing or quitting.

Re: On Being a Principal Engineer

#303

Post by man007 »

I've been working as a Principal Engineer for the last year. This experience is similar to what I've experienced. Coordinating across teams, help unblocking coworkers, distributing knowledge etc. I've worked with the same company for the past 3 years, and as a result, I know the historical decisions etc. Unfortunately, as a result, I am spending less time refining my craft and coordinate business needs with technical solutions.

From an organizational standpoint, I believe I add much more value in this role compared to strictly writing code. Unfortunately, the skills you learn tend to be localized to the place you are working at, and are not really transferable.

It's been a good experience, and I've grown my soft-skills as I've had to handle different scenarios.

Re: On Being a Principal Engineer

#304

Post by ahupp »

kanox wrote: post #292
leetrout wrote: post #216

Earlier quoted context omitted.

I left my previous company before their ladder (~14+ months of work) was finally released so I'm not sure how it has worked out but one of the first drafts I saw had a rubric for gauging your growth / fit for the roles. One of the biggest things I took issue with was that you had to have some sort of "community involvement" but management had to approve your speaking engagements to some degree (be it time off, messag…

> "but you are too emotional" to promote. Jesus fucking Christ how is that even remotely acceptable as management feedback?

That seems like fine feedback as long as it was coupled with further specific and actionable feedback. e.g, "You yelled at Alice and Bob in the discussion about project X, rather than helping build a consensus about the right solution." Senior engineers should be solving problems in the org, not causing them.

Re: On Being a Principal Engineer

#305

Post by prirun »

2muchcoffeeman wrote: post #144
jameshart wrote: post #120

Earlier quoted context omitted.

The challenge I have interviewing people for very senior engineering roles is how to tell the difference between somebody who was nearby when some interesting work got done, and somebody who made something interesting happen . What I’m looking for in a principal engineer is someone who turns good teams into great teams; who steers the organization away from disastrous mistakes; who enables the business to accomplish…

> It’s something that comes hard to senior developers, because we’re all aware that every result is a team win. So when you’re asked about a project you worked on, you’ll tell the story all in first person plural: ‘we had to solve this problem, so we decided to use this approach’. As you said, good outcomes are team efforts. Even your best developer is not going to do anything great if he’s fixing bugs. Less senior d…

I sort of hate the idea that senior people design and write stuff, while junior people fix bugs. In my experience this leads to developing code where "someone else will fix it up if there are problems" and in the long-run, is not good for the senior people (they get sloppy) or the junior people (they're not happy fixing others' crappy code).

I think a lot better model is ownership of code. If you write something, it's yours. If it breaks, it's yours to fix. If someone wants to change the design of it, they go through you first. Maybe eventually someone changes it so much that they own it.

Re: On Being a Principal Engineer

#306

Post by 6ak74rfy »

nilkn wrote: post #173
md5person wrote: post #104

I appreciate the idealistic take on what a "principal" role should be like, but in all actuality, principal engineers are commonly the ones that simply stayed there long enough (ie. to survive multiple re-orgs), and played their politics cards wisely. They were playing the title game. Often, their work is invisible to most. They perpetuate tribal knowledge, and have trouble letting go of the past and accepting change…

This sounds like standard title inflation, and it's not restricted to just technical ladders. It's certainly a problem, but I don't think we should discount the idea of principal engineering roles just because job titles can be misused or abused. The company I'm at has a single principal engineer. He was hired externally. Within a year of starting, he'd had a bigger impact across teams than the CTO in the same time p…

This sounds like a great guy. Can you give some concrete examples of various techniques and technologies that he brought to the table?

Re: On Being a Principal Engineer

#307

Post by mlthoughts2018 »

skj wrote: post #295
mlthoughts2018 wrote: post #281

Earlier quoted context omitted.

In that case, I would politely thank you for the chance to interview and decline to speak further with you, because it would be clear I would not be empowered to get my job done in the face of all the time-waster politics to lobby for projects or quarterly goals, etc. I would feel, “why have they hired an expert like me if they don’t plan to trust my advice on what action to take?”

The statement > anyone who comes in as a Staff Engineer expecting to simply dictate their ideas to lower-ranked engineers without selling those ideas, is going to fail was almost certainly about the field in general, not this person's immediate org or even company. So it's more like, "why would we hire an expert like you if we won't actually get the value we're paying for?"

> “So it's more like, "why would we hire an expert like you if we won't actually get the value we're paying for?"”

But hiring them into a position where they are automatically subject to pre-existing political barriers guarantees you won’t get value out of them.

Giving them autonomy means you could possibly benefit from their value-add.

Re: On Being a Principal Engineer

#308

Post by ahupp »

jedberg wrote: post #129

Re: companies that claim to have a fully equivalent technical track: What I've found is that is mostly lip service. Yes, they publish salaries and requirements for the highest levels of engineering, and those salaries are equivalent to high levels of management as far as pay goes. But if you look a little deeper you see the problem. At Google and Amazon and Facebook, a Distinguished Engineer is equivalent to a Vice P…

The VP/DE ratio just reflects how likely it is to have that level of impact. A VP is typically not just "a great manager", they drive the product vision and ensure you're building the right things. A great engineer can produce similar impact but it's a lot less likely.

> if you actually want to have a chance of moving up to those levels of pay, you had better go into people management

Your own strengths and weaknesses as an individual are are much more important part of this decision than the baseline probabilities of becoming a DE or VP.

Re: On Being a Principal Engineer

#309

Post by mlthoughts2018 »

nf05papsjfVbc wrote: post #289
mlthoughts2018 wrote: post #281

Earlier quoted context omitted.

In that case, I would politely thank you for the chance to interview and decline to speak further with you, because it would be clear I would not be empowered to get my job done in the face of all the time-waster politics to lobby for projects or quarterly goals, etc. I would feel, “why have they hired an expert like me if they don’t plan to trust my advice on what action to take?”

Do you really think software engineers react well to being told what to do by someone who has not yet earned their respect?

That seems inapplicable. This part of the comments is just about being given the political authority to implement the course of action you determine is best.

Of course that always starts with developing trust and belief from the engineers and probably even needs to be based on what they know and their experience.

That’s a separate issue from being a political lame duck hire who, even with engineer support, is blocked from being effective.

Re: On Being a Principal Engineer

#310

Post by mixmastamyk »

hn_throwaway_99 wrote: post #250
zyncl19 wrote: post #175

Earlier quoted context omitted.

I would argue that for a Distinguished Engineer to have as much impact as a run-of-the-mill VP, they have to be the best at the world at what they do.

I agree completely. And as someone who has had senior engineering roles and senior engineering management roles at different times, I'd argue that the reason management is paid more is simple supply and demand. For a very large majority of people, managing people is basically a more difficult, stressful, and shittier job. Not that there aren't a small(er) group of people who really love management, but management sal…

Huh, I'd argue more folks are interested in management then are being engineers.
Post reply on HN