Live data from Hacker News

The Staff Engineer's Path – Book Review

smyachenkov.com

181–190 of 251 posts

Re: The Staff Engineer's Path – Book Review

#181

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 Well, we know stories behind each of these: - linux kernel: comp sci Msc student - redis: written by a startup founder (in TCL[1]) - next.js: written by a founder of Vercel (as "Zeit") - rollercoaster tycoon: written by one dude in scottland None of these people are Staff Engineers, in the sense of this book. You may find a few travel…

These are all much more similar to the work of inventors than engineers.

Except Rollercoaster Tycoon, which is more like the work of an artist.

Like, coming up with Linux is a lot like Guglielmo Marconi putting together a working radio transmitter/receiver in his parents' attic.

These things can overlap. Art Fry, inventor of the Post-it note, was in a kind of 'principal engineer' equivalent role at 3M when he came up with it (he was the senior scientist in a lab team).

Re: The Staff Engineer's Path – Book Review

#182
post #145

Earlier quoted context omitted.

> sometimes your job as a BDFL may be to say "no" to your most ardent supporters. This also happens a lot for staff level platform work. You hit the nail on the head. You've heard of a "yesman" (i recognize the sexism in that phrase, but it is the colloquial term), people that simply say yes to everything. I always joke that I am a "no-man". My job is literally to say "no" to probably 12-15 people a day. I say "yes"…

Why are your people asking so many bad questions? Good questions are "how can we X?" And good answers are "here's how: Y" Then the asker decides if they are willing and able to Y.

Most of these kinds of questions have to do with feasibility, where the question asker doesn't have all the context needed to:

1) Decide: is this worth it for the business? NOW?

2) Delegate: ok, we've decided it's worth it NOW. Who is best equipped to execute?

So, that's not a "bad question."

Most of the time, saying "no" also comes with helping the requester de-scope to meet the crux of their obligations, save face on any commitments they won't be able to meet.

Saying "yes" means figuring out what the work will displace.

A significant part of my job as a staff infrastructure engineer was carrying this kind context between planning rituals with various time horizons, ranging from weekly to quarterly to annually.

Occasionally I would drop down into execution mode myself to knock out something particularly gnarly, or set up some pins for someone else to knock down (e.g. promo season).

Re: The Staff Engineer's Path – Book Review

#183

Earlier quoted context omitted.

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 in…

Title inflation isn't specific to tech. Look at the banking industry, pretty much everyone is a VP or SVP of something.

Re: The Staff Engineer's Path – Book Review

#184
post #74

Earlier quoted context omitted.

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…

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…

Perhaps the word you're looking for is perseverance?

Re: The Staff Engineer's Path – Book Review

#185
post #71

Earlier quoted context omitted.

Can you explain better the difference? I am trying to figure this out myself for a while...

Typically the direct reporting relationship is about managing someone’s career and not necessarily their work. The leadership described here is more about the work to be done rather than the person’s fulfillment and suitability with that work. This separation is more pronounced with large (1000+) engineering organizations. Often people don’t experience this difference because it doesn’t exist at the smaller scales. E…

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.

Re: The Staff Engineer's Path – Book Review

#186

Earlier quoted context omitted.

Yes. All the FAANGs have such roles. Sure, most PEs are "applied" engineering or management right-hands, but the same companies have PEs up to VP/Distinguished Engineers deep in technology... React came from Facebook, Google employees James Gosling (Java), Jim Roskind (QUIC) is formerly Google currently Amazon... at all these companies, there's a ton of deep technology the public hasn't even heard of.

How do you find those teams and that work... or is it a matter of those companies finding you because of your open source work? For example, Google hiring Robert Griesemer, Rob Pike, and Ken Thompson to create Go?

You either need to find something adjacent to what you already do, or you need to build trust where you work and jump on any opportunities that come up. You can get noticed for work by giving conferences talks or being active on the right mailing lists or getting to know the right people.

In my career I built trust internally and so got interesting work. I talked about that work and so got approached about other jobs, and I’ve been able to move when I’ve wanted to because I’ve kept in contact with some former colleagues.

I would however like to stress that the most important point of this is doing the aork, and doing it well. If you don’t do that then everything else is pointless.

Re: The Staff Engineer's Path – Book Review

#187

This cult of staff engineers really need to go away. People read it and all of them like to act like a staff engineer when in fact there are only available slots for a fraction of the engineers. Now nobody wants to fix bugs and improve product quality. Why? Because those tasks are not staff-level work. The reward system and the definition doesn't work.

I strongly disagree. “Staff engineer” as a construct should be understood as an alternative to the previous dominant paradigm, which held that manager track is the only progression track beyond some point (usually Senior or a “Senior II” level).

This toxic concept was pretty commonplace through 2010, particularly outside Silicon Valley.

Any system can be done wrong. But this system is, I believe, objectively better than the one preceding it, as having a dedicated IC track gives a way of growing your engineers who aren’t interested or talented in management.

What you are complaining about sounds like an instance of poor management or poor team composition, not anything to do with the concept of Staff Engineer; if people are not doing their job then they are not being performance managed properly. Showing you can act at the level above is great but you still need to nail your core responsibilities too.

Re: The Staff Engineer's Path – Book Review

#188
post #99

Earlier quoted context omitted.

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…

> 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.

Re: The Staff Engineer's Path – Book Review

#189
post #74

Earlier quoted context omitted.

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…

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.

So when you’re looking for that role after you think you’ve got that stamina/perseverance/commitment, do remember that maybe you still have to find that right place to work at.

Re: The Staff Engineer's Path – Book Review

#190

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…

Dogma in the tech industry is that the ceiling on individual contributions is close to the median. That the leverage is all in coordinating larger groups of engineers. Belief in, affection for, or aspiration to be the lone-wolf super-genius coder who does something transformative in his own editor is a negative signal, associated with "brilliant jerk" and "not a team player" archetypes. Tech companies are generally s…

And the stronger this rejection, the stronger the pressure on anyone who represents a counterexample to the dogma to leave.
Post reply on HN