Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

231–240 of 337 posts

Re: On Being a Principal Engineer

#231

Earlier quoted context omitted.

Oh man, I see so many resumes littered with these kinds of statements. I totally gloss over them as they generally read like BS, and are formulaic enough that they just represent another "how to sell yourself" job-hunting checkbox point. Lots of devs would love to have some way to quantify our impact in monetary terms but the reality is that "process/tooling change X -> $Y ARR" is basically always hand-wavy made up m…

Sure, but most business decision making is based on hand wavy made up math. Like, how do you decide to build a feature or switch programming systems? Does it not relate to customers or revenue? Also, yes, don’t have the numbers be BS or fail to include other useful narrative in your resume. But I so often see none of this, and leaving it all out is a sign someone hasn’t had to justify their decisions at that level.

It is task of decision making person to filter out hard facts from BS. If he does good job - company is more successful.

Re: On Being a Principal Engineer

#232

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…

Interesting. At both Amazon and my current employers, engineers at that level have to be able to both talk-the-talk and walk-the-walk. No resting on laurels and being buried in the past.

Anecdotally, one of the distinguished engineers at my current place came from a similar role in Google. They left Google because they kept putting them and a number of other distinguished engineers on products and projects that would never see the light of day, or be turned in to an actual project.

Re: On Being a Principal Engineer

#233
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…

>A lot of the value that I add now is because of the historical knowledge I have. What we have tried as a company, what we haven't, why we built some things the way we did, how things work currently, how the politics works and the trust I have built.

Outside of the politics and trust portion, most of this should be well documented and not something that relies on a person being around. What's been tried, and why, should all have documentation around it - what worked, what didn't, how the decision was come to, what data points were considered, etc. All of that is valuable, and it should have all been documented along the way to help back up the decision making process to begin with.

When the time comes to make decisions in that same vein, people can review the previous process. Maybe they have new information to bring to the table. Maybe they didn't account for something that was considered last time. Maybe the "you" of whatever process is no longer with the company.

I'm in a similar position to you. I've made it a mission the past couple of years to try and eliminate myself as a single point of failure for this sort of information.

To the second point, just because the job posting isn't there doesn't mean the job doesn't exist. Companies might not be looking to necessarily hire a staff engineer specifically, but could see the value in one if the right candidate appears.

Re: On Being a Principal Engineer

#235
post #218

Earlier quoted context omitted.

I'm super appreciative of my current role for this and other reasons. I'm the sole software developer on a team of 6 people in a mostly isolated corner of the code base. I'm getting a ton of experience making calls and collaborating with non-engineers, while still getting to be involved in some broader discussions. A company of 20-50 programmers seems ideal to me now, with an overall company size of <300. I feel larg…

I wouldn’t go that far. Being the sole developer you risk becoming an “expert beginner”. I know that held me back for over a decade, being the only developer for three years and working with two other developers who never worked at any other company for 9.

I’m might be in this boat, and it terrifies me.

What are some characteristics of a “expert beginner”? What did you realize you were lacking/weak points?

Re: On Being a Principal Engineer

#236
post #74

Earlier quoted context omitted.

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

As an example, I recently got offered a Senior Software Engineer position with 6 months experience @ Zendesk.

my whole dept seems to be filled with seniors younger then me, except my manager thinks the title still means something at this point so i'm not being considered for senior for years. im asking to be senior because i just want the money fuck the titles...

Re: On Being a Principal Engineer

#238

Earlier quoted context omitted.

This is the very thing I'm criticizing. "Leader" is one of the worst buzzword bingo terms in a company. It means nothing, it's just a convenient label to give people who you feel like promoting to maintain the 10:1 ratio. You could argue Linus Torvald is an industry leader, or you could argue he doesn't show adequate leadership for cross-team.

I think you very much understand a leader can be something more than a buzzword: "If you’re a leader in an organization, you need to be aware of the stories that occupy the minds you oversee." Or maybe more succinctly: "If a great manager screws up, he should lay awake at night until he fixes it, just as a great engineer would wake up to fix a production issue." These traits combined with a scope of influence is what…

Well, that very post is criticizing self-proclaimed organization "leaders" for not holding themselves to the same level of basic accountability as a senior engineer would.

I do believe in leadership, in the abstract. But at the end of the day companies do whatever the hell people in power choose to (e.g. Fire Steve jobs, promote their friend, hire somebody sexy) and then come up with fancy meaningless words after the fact.

"Force multiplier" and "cross-team leader" are among those. If you really wanted to promote "leaders" then have engineers vote on who gets promoted...

Re: On Being a Principal Engineer

#239
Curiously, I'm trying to validate RefactorKit.com which will help with these "soft-skills" like: - stakeholder convincing campaigns - org collaboration signals - consensus building

I've never heard of a principal or staff engineer before. I'm up on Twitter as @refactorkit, find me there, would love to chat

https://refactorkit.com

Re: On Being a Principal Engineer

#240
post #69
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

Cronyism is what you call it from the outside; networking is what you call it from the inside.
Post reply on HN