Live data from Hacker News

The Staff Engineer's Path – Book Review

smyachenkov.com

241–250 of 251 posts

Re: The Staff Engineer's Path – Book Review

#241
post #126

Everyone in this comment thread seems to have a different definition of staff engineer. And that is kind of the problem with this term. It's almost devoid of any meaning now, like the ubiquitous VP title at a bank. This book should probably be titled "Being a staff engineer at big tech - how to navigate the performance process to get promoted as an IC". From my brief skim, that seems to be what it's about.

I've been reading the book and I agree with you regarding the book being very specific to a type of company culture. I still find some of its ideas useful, not because I didn't think about them before, but sometimes it helps to organize your thoughts when someone else is talking about them out loud. Not a life changing book but useful still.

[deleted]

Re: The Staff Engineer's Path – Book Review

#242

Earlier quoted context omitted.

When you say "about managing someone's career" I can't help but feel you actually mean "someone's job". No manager is paid to care about an employee's career that I have ever seen or heard of.

Ehh, I am employed at a company where, despite things being very tense at the moment, I've felt very comfortable expressing to my manager my intent to transfer out of the team I'm currently on and into a different position, as I'm not happy with things as they are. My manager, skip, and director have all been extremely supportive of this throughout the process, despite it taking a somewhat lengthy period of time and…

A different position at the same company? That's a job.

Re: The Staff Engineer's Path – Book Review

#243
post #223

Earlier quoted context omitted.

Almost each of such guys didn’t have to respond to Jira tickets and answer to shit asked by PMs and TPMs on a daily basis while standing in a circle and showcase/demo “progress” weekly, be part of a trillion meetings in a day, while also preparing documents for things you provably never understood the why of, and in general justify your existence there in a quantifiable way to every TDH in the team and the company. S…

Tall, dark and handsome?

probably "Tom, Dick and Harry" in this context, meaning everyone

Re: The Staff Engineer's Path – Book Review

#244

Earlier quoted context omitted.

I think it's the complete opposite. There are very few businesses that can exist without having to solve an enormous amount of edge cases. Most of the time that's the whole reason the business is valuable! Also, this shouldn't be framed as 10x more code but 10x faster velocity. That is what I meant by "[staff developers] are not good at writing 10x more LOC than other developers". Staff devs cannot move 10x faster th…

Well, yes, I mean, how can we really have this conversation and throw numbers around without defining even what countries and industries we are talking about? But, maybe it's true that most code covers edge cases; then in my opinion, staff developers should be building tools for the rest of the company to use, and if they are powerful enough, you might be better off by having fewer people employed as programmers and…

Like I said, I think most companies don't fit your model so feel free to throw out some industries.

I think service/API companies like Netflix are the most suited to your approach, but even with Netflix leaning into that style of company hard they still have thousands of engineers. There is most definitely some amount of irreducible work for a problem/domain/other.

> Obviously a lot has to go right for this sort of thing to happen

It feels like a very naive approach. When I'm building stuff, the edge cases often require a lot of digging into the surrounding context and working with other teams.

I don't think you can solve this by abstracting it away, because it's still working at the same level of abstraction just in a different part of the codebase.

There is also the fact that every abstraction is leaky...

Re: The Staff Engineer's Path – Book Review

#245
post #236

Earlier quoted context omitted.

When you say "about managing someone's career" I can't help but feel you actually mean "someone's job". No manager is paid to care about an employee's career that I have ever seen or heard of.

> No manager is paid to care about an employee's career that I have ever seen or heard of. This is an incredibly common part of the role(s), so my guess is that you have been unlucky in this. For what it's worth, all the strong managers I've ever know or worked with pay attention this this, and vast majority of companies (again in my experience) made it an explicit part of their role. I'd go so far as to say as a peo…

> This is an incredibly common part of the role(s), so my guess is that you have been unlucky in this.

I could be very unlucky, sure, but I've worked at my fair share of places and it's always been the same. Management is there to keep the cats herded and HR is there to make sure nobody fucks with the money. All that matters is that I do my job and that the employer can use the manager to push more work on me under the guise of setting myself up for a promotion or raise that will never, ever come - it never has.

> all the strong managers I've ever know or worked with pay attention this this, and vast majority of companies (again in my experience) made it an explicit part of their role.

All enhancing an employee's career does is ensure that they have leverage to negotiate higher salaries or leaving the company. No company wants this.

> I'd go so far as to say as a people manager (as opposed to a project manager, say) you cannot do a great job without considering things like career progression, because if you don't, you don't understand your team well enough to be really effective.

Sure, you know where strengths and weaknesses are but that doesn't mean you devote company resources to making the employee better suited for leaving the company. You can do things like growth but you're going to come around and put penalties and fees to prevent the employee from leaving voluntarily.

I have never seen any manager or business treat an employee's career as anything but an inconvenience at best nor have I heard of any of my coworkers or friends or family having experienced anything like this. I can only assume that it doesn't exist or that it is so rare that it may as well not exist.

Re: The Staff Engineer's Path – Book Review

#246

Earlier quoted context omitted.

> But you couldn't reimplement podman in a few hundred lines of code. You don't even need a few hundred: https://github.com/p8952/bocker And then there's 'dokku' which IIRC, started as a bash version of Heroku. > Not all ideas have the same quality. They really do. I've heard all kinds of things in my career, but almost none I would want to dedicate a portion of my life building. Not because they are bad ideas or won…

That would prove my point though. If it actually is that easy to implement then podman is more in the “good idea” than complicated implementation category as well.

It is an idea, and podman wasn't the first (by far) to come up with something. They just had good timing and marketing. That is what is truly important: execution of the idea.

Re: The Staff Engineer's Path – Book Review

#247
post #236

Earlier quoted context omitted.

> No manager is paid to care about an employee's career that I have ever seen or heard of. This is an incredibly common part of the role(s), so my guess is that you have been unlucky in this. For what it's worth, all the strong managers I've ever know or worked with pay attention this this, and vast majority of companies (again in my experience) made it an explicit part of their role. I'd go so far as to say as a peo…

> This is an incredibly common part of the role(s), so my guess is that you have been unlucky in this. I could be very unlucky, sure, but I've worked at my fair share of places and it's always been the same. Management is there to keep the cats herded and HR is there to make sure nobody fucks with the money. All that matters is that I do my job and that the employer can use the manager to push more work on me under t…

> All enhancing an employee's career does is ensure that they have leverage to negotiate higher salaries or leaving the company. No company wants this.

Explicitly, no. Growing talent inside is far less risky than hiring from the outside. Sometimes that means someone will leave, yes - but if the relationship is good they will do it at the right time when they are ready, not when they are miserable. This is win win. Long term net positives here are hard to understate.

> I can only assume that it doesn't exist or that it is so rare that it may as well not exist.

Well I can equally attest your assumption is false. But this is probably just a demonstration that path dependence is a real thing.

All I can say is you have a very negative view of the whole situation, which doesn't match my experience at all, or that of many people I know.

Re: The Staff Engineer's Path – Book Review

#248

Where do all the hardcore engineering jobs live? I've been bothered by the fact that most advanced engineering roles like "staff" actually mean "manager who does system design as well" Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? Where are the people creating amazing software and do they get a special "advanced developer" title? I guess, I'm curious if there are actual roles in c…

The exact idea of the Stuff Engineer is that they are not managers. They are leaders though, it is a different matter.

Re: The Staff Engineer's Path – Book Review

#249
post #236

Earlier quoted context omitted.

> No manager is paid to care about an employee's career that I have ever seen or heard of. This is an incredibly common part of the role(s), so my guess is that you have been unlucky in this. For what it's worth, all the strong managers I've ever know or worked with pay attention this this, and vast majority of companies (again in my experience) made it an explicit part of their role. I'd go so far as to say as a peo…

> This is an incredibly common part of the role(s), so my guess is that you have been unlucky in this. I could be very unlucky, sure, but I've worked at my fair share of places and it's always been the same. Management is there to keep the cats herded and HR is there to make sure nobody fucks with the money. All that matters is that I do my job and that the employer can use the manager to push more work on me under t…

Every org has different cultures and leadership culture within it.

A power culture has zero trust and is high blame. Bureaucratic is process oriented. Generative experiments, tests, learns from failure.

The organization you have never experienced is generative. And coupled with transformational leadership it’s a pleasant environment to work in as either a manager or IC. These orgs do exist and are not rare either.

Re: The Staff Engineer's Path – Book Review

#250

Earlier quoted context omitted.

Well, yes, I mean, how can we really have this conversation and throw numbers around without defining even what countries and industries we are talking about? But, maybe it's true that most code covers edge cases; then in my opinion, staff developers should be building tools for the rest of the company to use, and if they are powerful enough, you might be better off by having fewer people employed as programmers and…

Like I said, I think most companies don't fit your model so feel free to throw out some industries. I think service/API companies like Netflix are the most suited to your approach, but even with Netflix leaning into that style of company hard they still have thousands of engineers. There is most definitely some amount of irreducible work for a problem/domain/other. > Obviously a lot has to go right for this sort of t…

We should be building tools that empower people to solve their own problems, whether that's no-code or low-code tools, or platforms, or scripting languages. We underinvest in internal tool-building for all sorts of non-technical reasons, and the result is people interacting all day at work with terrible software.
Post reply on HN