Hacker News Reader

Comment by nine_zeros | Hacker News Reader

I have personally become quite tired of "staff" engineers at my company. They get paid a lot but not only do they not actually code or fix bugs - they don't even make good design decisions or good calls. They are absent when needed, can't drive projects to completion and punt tough calls over to senior engineers who actually understand the system.

The only reason said senior engineers are not staffs because the staff engineers have been gatekeeping to maintain an aura of selectivity.

No wonder people end up quitting so often.

View on HN

That sounds like a bad situation but as to your first point, code is toxic effluent so if your more senior engineers seem to be writing less code, that’s the wisdom of experience.

Less code is not less lines of code. What I mean is that they write less as a percentage of the total amount of code/configs to be written. Most of the actual work is done by non staffs.

This is usually true just as a function of what the job is, for better or worse.

I'm a senior eng on track to staff, and the fact is that code is rarely a scalable enough output. Often the problems I'm solving are hard enough that they take a while to investigate, so if they have ultimately easy solutions, it means I write a one change a week or something. And in a lot of other cases, I'm doing something "the first time" and then making sure that everyone knows how to do the and process. So I'll write code once, but it'll be used as an example by tens of other engineers.

The thing that I work on where I write the most code (a cleanup of tech debt) won't really help me get to staff unless I scale up the approach, which would require me to shard the work out among a bunch of other people. Because of the scale staff eng works at, writing code becomes less integral to the job, and often a somewhat negative signal.

While true, the onus of making tough calls should be on the person with the title.

Less code is a proxy for not really understanding the ground reality. Often staff engineers end up with hand wavy designs with no clue about how it would get executed. They get defensive/frustrated when some senior engineer points out a flaw in their plan.

To be an effective staff, the staff has to be in the trenches, lead by example. Not by writing a few docs and brushing off their hands.

> Often staff engineers end up with hand wavy designs with no clue about how it would get executed. They get defensive/frustrated when some senior engineer points out a flaw in their plan.

This sounds like you've described an Architect (circa ~2003), rather than a Staff engineer of any standard. Perhaps your company has a serious engineering leadership problem. I'm sure this problem is common at many companies but I'm not sure this can be generalized to the Staff title.

To me it’s about giving advice and sharing experience. A senior engineer or tech lead might have a problem and I give more context, and talk about similar situations I’ve seen in the past or put them in contact with another team, but they make the call since it’s their team and their responsibility. Might be seen as “punting”, or as trust and empowering.

Reply on news.ycombinator.com