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.
On Being a Principal Engineer
231–240 of 337 posts
Re: On Being a Principal Engineer
#232I 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…
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
#233This 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…
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
#234?
Re: On Being a Principal Engineer
#235Earlier 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.
What are some characteristics of a “expert beginner”? What did you realize you were lacking/weak points?
Re: On Being a Principal Engineer
#236Earlier 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.
Re: On Being a Principal Engineer
#237Re: On Being a Principal Engineer
#238Earlier 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…
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
#239I've never heard of a principal or staff engineer before. I'm up on Twitter as @refactorkit, find me there, would love to chat
Re: On Being a Principal Engineer
#240Earlier 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