Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Staff Engineer's Path – Book Review

smyachenkov.com

Post reply on HN
Print view View original

221–230 of 251 posts

Re: The Staff Engineer's Path – Book Review

#221

Post by mgaunard »

lhorie wrote: post #58
Xeoncross wrote: post #15

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…

Big tech companies have entire departments dedicated to this sort of engineering, usually developer platform/experience/productivity, or other similar infra/platform orgs. I'm an author of an open source framework who got scouted to work at one (and I'm currently a staff eng). IME, yes there's comparatively far more CRUD roles than platform roles. But bluntly speaking as someone who's been on both sides of the fence,…

You just explained exactly what's wrong with big tech companies.

Application/product developers are seen as less capable and they put their best developers in infrastructure/platform/sdk/libraries.

This is all completely backwards. The application is what generates revenue and what needs the most attention to ensure the tech is a good fit. The needs of the application should be what drives the infrastructure to support it, but instead those companies have infrastructure people call the shots and heavily constrain how all applications should be built.

Thankfully there are sectors where application developers have full freedom on their tech stack in order to satisfy their business requirements and infrastructure is just people maintaining a collection of tooling and services that others can opt in to use or not.

Re: The Staff Engineer's Path – Book Review

#222

Post by gizmo »

Meszek wrote: post #42
eatonphil wrote: post #24

Earlier quoted context omitted.

One area to find great engineers (and interesting jobs) is at database, infrastructure and devtools companies. Places like Cockroach, PlanetScale, Docker, JetBrains, CodeWeavers, Fastly, etc. And the databases, infrastructure or tooling teams within Meta, Microsoft, etc.

I'm at a point in my career when I need to decide if I want to work for European branch of American Big Tech or try a 20 people database startup (got offers from both). I've got 2 yoe in high performance c++, working on data processing engines. I'm really tempted to go to the startup... But big tech pays more. And I feel like I could actually learn how to use tools properly before I come back to writing them. Any opi…

Database startups really struggle because they compete with free and most database users need very little from their database. Enterprise customers do have advanced needs occasionally, but often it’s just about hoarding data or tracking users, neither of which does anything for society. Database startups are unusually hard because the real customers don’t want to pay and very few founders are able to get the hard tech right and are also willing to do the schleppy work of scaling up an enterprise sales team/process.

Re: The Staff Engineer's Path – Book Review

#223

Post by Y_Y »

crossroadsguy wrote: post #189
timacles wrote: post #94

Earlier quoted context omitted.

The thing that separates those guys from everyone else is simple. Its stamina. No there isn't some higher level of understanding or deep perception. Every one of the all time great programmers had 1 exact thing in common with no exceptions. Stamina. You will not find a single outlier. They did their craft every day, for many hours, year after year. So sure, any of us could have taken the individual small steps. But w…

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?

Re: The Staff Engineer's Path – Book Review

#224

Post by ZephyrBlu »

inimino wrote: post #188
ZephyrBlu wrote: post #142

Earlier quoted context omitted.

> These people do stupid CRUD API micro-service bullshit because they're blissfully ignorant of how tremendously amazing their software could be if they fired 90% of their boot-camp dev ops and replaced them with a handful of 10x staff-level developers I wish this was true, I really do. But a few staff developers cannot physically handle the volume of work required to replace that many developers. Staff developers ar…

Obviously, it depends on the work (why would we try to have a discussion like this without setting parameters?). But in general, I think the places that need 10x the code are outnumbered by the ones that would be better with 1/10th the code they have, written by fewer people. It doesn't happen, but that's better explained by organizational reasons.

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 than average devs on every problem.

Most work is undifferentiated. Staff developers don't add much value over another dev for basic work (Code quality has high diminishing returns) and they might only be 2-3x as fast, if that.

It's possible that many businesses could be sustained as they currently are today with 1/10th of the code and/or 1/10th of the people, but in a growing company that's impossible.

Re: The Staff Engineer's Path – Book Review

#225

Post by arnvald »

msoad wrote: post #2

I'm a Staff Engineer, but I hardly do anything that this book describes. Maybe it's my company, but we have so many Staff Engineers that if we all were to do this stuff, nobody would have time to do the actual work and there would be too many people trying to lead. Perhaps the levels are diluted and my title doesn't match my actual role at my company, but it feels like this is an industry-wide phenomenon.

What’s your ratio of staff engineers to all engineers?

I always think of staff as engineers working across multiple teams, so there should be ratio of 1:15 to maybe 1:30 (or in another terms, staff engineers should represent 3-7% of all engineers). If the ratio is smaller, like 1:5 or 1:8 then staff engineers are really just senior engineers

Re: The Staff Engineer's Path – Book Review

#226

Post by ThinkBeat »

""Know why the problem you’re working on is strategically important, and if it’s not, do something else.""

Yeah. Just tell your boss

"" I refuse to work on the assignment you gave me. Give this assignment to someone who has not read this book I will only work on strategically important assignments. because that will help me get promoted and noticed faster. ""

Re: The Staff Engineer's Path – Book Review

#227

Post by kmilinho »

nvarsj wrote: 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.

Re: The Staff Engineer's Path – Book Review

#228

Post by TrackerFF »

onion2k wrote: post #74
Xeoncross wrote: post #15

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…

Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? Something I learned relatively late in my career was that really impressive work is the result of iterations in tiny steps. When you see something that makes you go "WOW! I could never do that!" you're seeing the final result of a long journey, and you probably could have taken each small step with a bit of effort. There's no need for…

Linux is a good example - Linus literally iterated on it as he was learning stuff in University, with the help of one of his classmate/friend. And IIRC, the very start of it was just printing a stream of characters or numbers which represented the output of parallel/asynchronous task handling. They just kept adding one feature after another, until they felt that it was "done" - but of course kept on building.

Re: The Staff Engineer's Path – Book Review

#229

Post by kaba0 »

feoren wrote: post #99
pc86 wrote: post #25

Earlier quoted context omitted.

> Most companies seem to be consumers instead of creators and only offer Jr.-to-Sr. level roles around making a CRUD API micro-service collection. That's because this is what 90% of companies need. Even at big tech or any nationally-known tech brand, I'd bet at least half the work in maintenance, support, incremental improvement, and integrations.

Sure: nobody wants the car, they just want faster horses. > Even at big tech or any nationally-known tech brand, I'd bet at least half the work in maintenance, support, incremental improvement, and integrations. That's because they are extremely inefficient. Most people build software badly, most companies expect software to be bad, and they hire a bunch of bullshit jobs to do inefficient things to support that bad s…

Disagree. While I always felt that I want to achieve more than these regular old CRUD apps, no “10xer” would implement them faster/better - because “these systems are building the rails in front of the train”, and it is not even an engineering problem most of the time. I have worked at banks and the amount of back-and-forth between what the bank wants and what the devs need to know is insane, not well specified, always changing, etc..

Hell, it is often the case that requirements change up the whole program logic based on which country it is being used from. It has a much different complexity than a JIT compiler, but it is a super-human, not-really-compressible complexity nonetheless.

Re: The Staff Engineer's Path – Book Review

#230

Post by kaba0 »

pc86 wrote: post #16
msoad wrote: post #2

I'm a Staff Engineer, but I hardly do anything that this book describes. Maybe it's my company, but we have so many Staff Engineers that if we all were to do this stuff, nobody would have time to do the actual work and there would be too many people trying to lead. Perhaps the levels are diluted and my title doesn't match my actual role at my company, but it feels like this is an industry-wide phenomenon.

I've always viewed the levels sort of like this, obviously very dependent on company: Juniors need hand-holding at every step. They may be new grads who don't even know how to behave in a professional environment or very inexperienced folks 1-2 years out of school taking a role in a completely different language they're unfamiliar with. You're talking to them anywhere from 5+ times a day to every other day as they tr…

I don’t know what kind of jobs you do, but there is no way on Earth that a senior architecht VP whatever will even start to grasp an “organically” grown monstrosity most places have mustered into being. Like, no matter how experienced someone is, the concept behind the whole thing is ill-specified, overly complex and not actionable upfront. It’s 1-2 months minimum that they can do useful work in my experience, and it has nothing to do with technological knowledge, simply the business knowledge is so vast.
Post reply on HN