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

41–50 of 251 posts

Re: The Staff Engineer's Path – Book Review

#41

Post by markus_zhang »

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…

Yeah I'm wondering the same. I have always been looking forward to doing something fundamental and those people are the ones I look up to.

Re: The Staff Engineer's Path – Book Review

#42

Post by Meszek »

eatonphil wrote: post #24
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…

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 opinions?

Re: The Staff Engineer's Path – Book Review

#43

Post by 0xbadcafebee »

JackMorgan wrote: post #12
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.

Titles are very much diluted. I've seen companies hire college sophomores who have never heard of the concept of a database and make them Sr Engineers on a analytics teams. I've seen Sr Engineers hired with one year of relevant experience. At this point, "Sr Engineer" is just the new "Jr Engineer". There's nothing wrong with this, but indeed, Staff Engineer tends to mean 8+ years of experience.

It's because we still have no standards as a profession. Whatever bullshit trends in silicon valley, suddenly everyone follows it, petrified that they might get left behind or are missing some important new thing.

I remember when Systems Administrator was a noble and important profession full of smart, talented people. But a lot of people misunderstood it and made fun of it, so it became an unattractive title, and instead of changing the role, they just made up new titles. Now they're cool and in-demand, and still nobody understands what they do.

Re: The Staff Engineer's Path – Book Review

#44

Post by mkozlows »

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…

The idea is that staff+ engineers can drive high-complexity work, right. There are arguably two types of that work:

1. Work where no individual component is complex, but there are a ton of moving parts and interlocking dependencies and interacting systems and so forth. A staff+ engineer is needed to drive this, but that job is less about writing the hard code and more about teasing out and resolving the hard interactions, so that kind of system design 'n' people role.

2. Work where there is a self-contained component that is very complex. A staff+ engineer is great to drive this, and may do so by writing the code themselves and reviewing other people's code as a developer.

In practice, many more companies have complex distributed systems than complex contained systems, but certainly both kinds exist.

Re: The Staff Engineer's Path – Book Review

#46

Post by UncleMeat »

Xeoncross wrote: post #34
UncleMeat wrote: post #27

Earlier quoted context omitted.

Software engineering . Most engineering is this way. Somebody needs to build a thing that isn't too different from other things on a budget and a timeline. Your typical civil engineer isn't designing a new burj khalifa. Most software engineering is about organizing a group of people to build a thing for a customer that isn't too different from other things, on time and on budget. There just simply aren't as many jobs…

So are we saying that software engineering can be at odds with your ability to write code? I'm not sure most people would say they are quite the dichotomy you present here. While I agree it's often a team-sport, being able to create amazing things yourself (i.e. Git, Redis, RollerCoaster Tycoon, Rust and other single-person projects) that others struggle to replicate or contribute too shouldn't mean you're a bad soft…

Not quite. I am saying that there is a meaningful difference between the process of working with other people over time and with resource constraints and writing software alone without time or resource constraints. Being skilled at writing programs doesn't harm one's ability to make decisions according to engineering principles.

I actually don't know for certain that writing Rollercoaster Tycoon in assembly was the not only possible way of doing it. But in popular consciousness it is usually discussed as a wildly difficult thing rather than the most efficient solution to a problem. That's anti-engineering.

There isn't really a good set of words to break down categorization. But I do think that the skills involved in the large majority of software engineering roles are pretty much entirely separate from the skills involved in writing some exceptionally difficult program.

Re: The Staff Engineer's Path – Book Review

#47

Post by pc86 »

Swizec wrote: post #28
pc86 wrote: post #22

Earlier quoted context omitted.

Curious your thoughts on who a Staff should report to. I've been at a handful of places where there were Staff Engineers (some of them even deserved it!) and it always seemed like the promotion from Senior to Staff came with a change in reporting structure, where now instead of reporting to a Manager you're reporting to a Director or a VP, even the CTO in smaller orgs. I think this is a good indication of increased a…

As a staff in practice, but not in title, here's how it works for me: My manager and I are at the same level. We work as peers. They handle the people stuff of the team, I handle the technical stuff of the team. They help with routing people/HR/management questions, I help with routing technical questions. If you think "Gosh, that person (on another team) sure was rude" , that's a question for my manager. If you thin…

This tracks with what I've read in your newsletter :)

Re: The Staff Engineer's Path – Book Review

#48

Post by pc86 »

dogline wrote: post #35
pc86 wrote: post #16

Earlier quoted context omitted.

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 think there's another past staff/senior where you get to tell all of the other groups to leave you alone, and you're back to being dirty and building cool things. This is where you're most valuable and where they want you. But, you need the confidence that you've got it handled and you're trusted to communicate as needed.

Yes this is the Guido/Rasmus level we should all aspire to!

Re: The Staff Engineer's Path – Book Review

#49

Post by eatonphil »

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…

That's a really personal decision but if you want to send more details I'm happy to give a more thoughtful response. My email is in my bio.

Re: The Staff Engineer's Path – Book Review

#50

Post by 0xbadcafebee »

bgirard wrote: post #7

> Put non-meetings on the calendar I'd love to do that. But once you throw in real meetings, no meetings days, PTOs, time zones it becomes difficult to schedule a work meeting because now there's no overlapping block of time when you need to meet. Now all meetings get pushed out even more and the calendar time required for certain tasks increases.

This is a feature, not a bug. Most meetings could have just been an e-mail or a slack thread. They don't want to spend 20 minutes writing an e-mail, so instead they spend an hour in a meeting where they find out they still need to spend 20 minutes thinking about something and writing it up. People need to learn to work without meetings. Open Source projects get work done with virtually no meetings at all.
Post reply on HN