My thoughts on this in a short post - https://medium.com/@kashifrazzaqui/a-simple-career-ladder-fo...
On Being a Principal Engineer
241–250 of 337 posts
Re: On Being a Principal Engineer
#242Earlier quoted context omitted.
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?
https://daedtech.com/how-developers-stop-learning-rise-of-th...
Unfortunately, you may not know until you get around people who have been developing as long as you have on paper but have learned from other people.
But this is my go to list of books.
Re: On Being a Principal Engineer
#243Earlier quoted context omitted.
> Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.” This is important for any level job. Java to Go by itself is really only interesting for a low level position. 8MM revenue growth is a person that will almost always get another look. In general,…
How does anyone quantify the value from something as generic as switching programming languages/frameworks to a number as specific as '8mm'? It could just as well have grown by that much even if there had been no switch. When I see formulaic nonsense like that in a CV, it better be meticulously sourced and they better be prepared to defend such a number in a potential interview, because usually I'll bin them with the…
One of the best things I've see engineers do to get their team the resources it needs is to spend time on modelling the value that they generate for the org. Speaking candidly... this could be any number at all, but most teams try to make it quantify the value generated in some meaningful way at least (even if that may not be admissible from a purely accounting/GAAP perspective).
e.g. it could simply be how much client data is processed by your system everyday, how many clients use it, what is the ultimate value the pipeline generates (even if that may be the cumulative value generated by the entire software pipeline)
Re: On Being a Principal Engineer
#244This article, along with a boatload of companies, fundamentally misunderstands the way that senior / principal / staff engineers add value. The article mentions it briefly in the small part about “force multiplier” but then seemingly reverses course when talking about “soft” duties & especially emotional labor. The value of staff engineers is to give them autonomy in deciding how to be a force multiplier. If they rea…
> burdening them to “sell” their vision on some architecture, recruiting policy, whatever.
Fair warning, if I ever interview you for a position of senior or higher, I will be evaluating your ability to sell your ideas to other engineers. 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.
Re: On Being a Principal Engineer
#245The relentless force of 'job title inflation' ensures there will be levels above Principal. (For instance, some organizations have 'Senior Principal'.) This is necessary because there are different grades of programmers. Frankly, some are better than others and social pressures force us to acknowledge it in some way. It's been this way as long as I remember, one of the first things I was issued at my first programmin…
Deflation involves lowering existing titles, which can lead to a lot of awkwardness even when done company-wide. As a result it's a lot easier to inflate than deflate. Thus the natural workplace dynamic you mention.
Re: On Being a Principal Engineer
#246Earlier quoted context omitted.
"But I am also at this weird point where I am not sure if the title of "staff/principle" can be transferred to another company. 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. " This worries me too. Within my company I…
I would argue that company-specific historical knowledge is not the value you (et al) are bringing. The value is the soft-skills of effective leadership that distinguish Principal from Senior (to use the article's parlance). Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills. And, of course, in finding a company and an interview panel that understands…
Building RefactorKit.com to help with this too:
> Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills.
Re: On Being a Principal Engineer
#247Earlier quoted context omitted.
Frankly, what you just wrote is what I want to hear in an interview. That you were first and the team grew around you and if mistakes were made how what would you do differently. To me, the company/team talk eats away at the limited time in the interview and doesn't generally matter since we are not hiring your company but how you helped is very relevant. I will slightly demerit people if I have to resort to asking w…
I feel I do great during the interview, it's just getting to that point is where I'm struggling. Writing that out seems to really bring out a part of my brain that makes it always feel braggy. (I really think it's the fact that during a conversation I have realtime feedback on what the interviewer wants and what parts I should focus on) I'm "full time" looking for a job at the moment, and it's rough with how much of…
> A lot of no responses, no way to gauge how i'm doing, and even when rejections come in there's no information along with them to help me understand why or how to improve
If you don't come out of an interview and know you have an offer coming your way: assume you have no offer coming your way. It's usually very obvious and both parties are trying to say your hired without actually showing your cards. It's kind of a funny dance.
Your problem, where you feel you have no feedback is a problem but it's most likely a problem with you.
You need to be asking for feedback if you're not getting it. Get blatant if you have to.
What do I need to show you to get an offer today? What are you looking for? Your job ad didn't clarify on this this and this, can you spell out exactly what you're looking for in me today?
You're not really responding to my answers, is there something I'm not explaining well enough? Feel free to interrupt and get me to clarify, this point is important to me because it illustrates this skill which I think is important as a developer, do you agree, disagree or don't believe me? Why? What facts do you need me to spell out?
If you think it's on them to figure out how to be good at interviewing, you're right, it is, but that doesn't help you get a job offer today.
Re: On Being a Principal Engineer
#248Earlier quoted context omitted.
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…
You believe there are qualities that good leader would exhibit — in the abstract — but experience has never offered mentor, teacher, motivator you respect thus all promotions must be based on facets unrelated to merit: ignorance, nepotism, and sexism.
You may want to ask yourself if your viewpoints are a case of WYSIATI bias or a generalizable fact about how businesses are run.
Re: On Being a Principal Engineer
#249Titles in software are so stupid. Where I work, everyone is “Software Engineer” whether they have 20 months of experience or 20 years. The respect and pay are commensurate with on-the-job performance and output. I know a “principal engineer” who can talk the talk, write books and articles but can’t produce any software of real value, and I work with a guy who’s been working 1/8 as long as me and he’s ten times better…
I see a lot of ridiculous titles, too. I think he addresses that in the "myth of a flat org" section. To continue his "all databases have schemas…even the ones that say they do not" metaphor: over-normalization is bad, too. It's hard prevent muddying titles with things like vanity, but a well-named title gives shorthand in large orgs or when new people come on. Of course knowing everyone individually is best, but tha…
*her for the record
Re: On Being a Principal Engineer
#250Re: 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…
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 salaries have to be higher because, if they were the same as corresponding IC levels, it would be very difficult to coax people into management.