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

71–80 of 337 posts

Re: On Being a Principal Engineer

#71

Post by erikpukinskis »

alexandercrohde wrote: post #53

Meh, nonsense. Standard buzzword bingo. Every engineer I meet advocates for standards. Usually the more dogmatic ones are the worse ones. This doesn't make you a 10x force multiplier (telling people to lint makes them 2% more productive tops). Usually these "standards" people though have a negative effect because they get into a dick-contest over the most trivial details (e.g. tabs/spaces). Even if cross-team collabo…

The two examples you gave, linting and tabs, aren’t architecture at all. They are toolchain.

Architecture is questions like should this class of functionality be services or objects and why? Do these 3 functions belong in this class, or should they be a helper? Should this helper be copied between repos or be a separate module with a formal API?

I agree with your point though that every engineer makes the decisions and having a separate role for them is weird.

Re: On Being a Principal Engineer

#72

Post by pault »

maxxxxx wrote: post #21
toomuchtodo wrote: post #10

Earlier quoted context omitted.

Staff/principal SWE compensation is the premium an org pays for your tribal knowledge, and arguably non-transferable. “Golden handcuffs”.

Outside the big companies in Silicon Valley there are no golden handcuffs for engineers. With each promotion you make just a few percent more.

I'm not sure about that. I moved to Austin three years ago and I have doubled my salary twice since I got here.

Re: On Being a Principal Engineer

#73

Post by dehrmann »

twblalock wrote: post #35
ryanong wrote: post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

Tribal knowledge is good to have, and inevitable, but it is also a blinder that tends to limit people to a particular set of architectural assumptions, and this gets worse the older the company becomes. It’s also an obstacle to bringing in new people. Some people are able to join a company and expand/modernize/build on the tribal knowledge to make things better. It’s a rare gift but I’ve seen a few people do it. Peop…

I've seen engineering leaders at companies with lots of tribal knowledge who have been there so long and are so committed to and defensive of old decisions that they're net negatives to the company. They're like helicopter architects.

Re: On Being a Principal Engineer

#74

Post by pault »

erentz wrote: post #23

Unfortunately the Principal title has been abused and cheapened by some orgs. In some ways necessarily, as comps in tech have grown it’s become necessary to hire people at a Principal level in order to get the necessary comp. In other orgs it’s been a way to lure people who are attracted to the title. Ideally Senior positions would be more respected and have a greater comp range. But now it feels like Senior is almos…

In my experience developers are going straight from junior to senior and "lead" is the new senior.

Re: On Being a Principal Engineer

#75

Post by bitL »

fouc wrote: post #69
bitL wrote: post #59

Earlier quoted context omitted.

I have seen how groups of people with dubious ethical standards played whole companies, pushing each other forward at the expense of more capable people, later taking their cronies with them to whatever company they landed, applying the same strategy. One of them made it to a director position at Google, largely propelled by "great networking". I can't with clear conscience support cronyism that deprives others of th…

cronyism and networking are quite different things though

I agree that in theory they are different, but in practice they seem to blend quite significantly (viewed with my sample size of 1 of course).

Re: On Being a Principal Engineer

#76

Post by maxxxxx »

mlthoughts2018 wrote: post #37
d4mi3n wrote: post #5

Earlier quoted context omitted.

In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.

I was hired into a company as a staff engineer, and I probably won’t consider it again. The existing engineers resented me for it, though it was super clear that the product was suffering because the existing engineers had serious skill gaps in critical areas. Meanwhile, to other managers & directors, I was just some new engineer they didn’t know, a political unknown quantity. I hit the ground running and earned a lo…

I have been in a similar situation as contractor. I would only do it again if I was in a position where I could ultimately call the shots. Usually that means being some kind of manager.

Re: On Being a Principal Engineer

#77

Post by maxxxxx »

pault wrote: post #72
maxxxxx wrote: post #21

Earlier quoted context omitted.

Outside the big companies in Silicon Valley there are no golden handcuffs for engineers. With each promotion you make just a few percent more.

I'm not sure about that. I moved to Austin three years ago and I have doubled my salary twice since I got here.

It depends probably where you are starting from.

Re: On Being a Principal Engineer

#78

Post by ww520 »

Those stated in the blog are leadership stuff which team leads and senior engineers need to have.

Principle engineers are simply people who can design and build a major product, a major project, or even a company's technology by themselves, alone if needed to.

Re: On Being a Principal Engineer

#79

Post by xixixao »

ww520 wrote: post #78

Those stated in the blog are leadership stuff which team leads and senior engineers need to have. Principle engineers are simply people who can design and build a major product, a major project, or even a company's technology by themselves, alone if needed to.

This is definitely the case of different organizations having different labels for the same thing. Going by the article, "senior engineer" would translate to "engineer" and "principal engineer" to "senior engineer" in our company.

The labels are not at all important though (and can be fuzzy still - big companies use explicit numerical levels).

Re: On Being a Principal Engineer

#80

Post by deleted_account »

erikpukinskis wrote: post #71
alexandercrohde wrote: post #53

Meh, nonsense. Standard buzzword bingo. Every engineer I meet advocates for standards. Usually the more dogmatic ones are the worse ones. This doesn't make you a 10x force multiplier (telling people to lint makes them 2% more productive tops). Usually these "standards" people though have a negative effect because they get into a dick-contest over the most trivial details (e.g. tabs/spaces). Even if cross-team collabo…

The two examples you gave, linting and tabs, aren’t architecture at all. They are toolchain. Architecture is questions like should this class of functionality be services or objects and why? Do these 3 functions belong in this class, or should they be a helper? Should this helper be copied between repos or be a separate module with a formal API? I agree with your point though that every engineer makes the decisions a…

These and the parent's examples are very team-centric. The heuristic I use when thinking about these engineering roles is, "Where is this person expected to be a leader?"

The progression is usually: Team, Cross-team, Organization, Industry. Competent technical decisions are table stakes. The real differentiator is at what level can they effect change.

Post reply on HN