The Staff Engineer's Path – Book Review

> 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't work, but because of the person with the idea or it just didn't interest me. Those people went on to be moderately successful (like hundreds of millions worth) but I'm glad I wasn't on that ride.

One thing I often see, I guess similar to game industry, the "cooler" the job the crappier the salary. E.g. automotive or avionics software gets written in Italy or Spain, paying (annual) 38K Euros to senior devs. Roller-coaster control software company in Argentina paying even less. I also often see such engineers moving into CRUD/PHP/JS for a much better pay.

It's certainly how they market themselves. Look how great we are, we're leaders, we're mentors, we're leaders, we think bigger, we make a bigger impact, blah blah blah.

And it's a crock of shit. It's not up to an IC to decide strategy, make executive decisions, or lead a team, unless Lead or Manager is in their title. Thinking big, prioritizing, choosing what to work on, etc, is something every engineer should learn to do, as part of a team. And that team should be led or driven by an individual whose job it is to, hierarchically, be in charge/responsible, and all that entails.

At the highest possible level, a staff engineer can be the "idea person" who looks at everything and can make proposals or lay some groundwork. But the "glue" of connecting a team to the rest of the organization needs to come from management and leadership, because they're the ones who can reach out to everyone without overstepping, and take the flack when it comes.

Here's another example: https://staffeng.com/guides/staff-archetypes/ This dude is claiming that these four separate roles and skillsets are just types of Staff Engineer. This is such ridiculous bullshit I don't think this person has actually done time in large engineering orgs. The tech lead doesn't even have to be very good, they just need to herd cats and be a tie breaker. The architect is an architect, a speciality distinct from the rest of software/systems engineering that doesn't even require coding. A "solver" is known in other circles as a "fixer", which is another word for someone who doesn't take shit and gets a job done, which doesn't require much other than willpower and attention. And a "right hand" literally is just shitty organization/management taking advantage of someone who gets things done yet has no political power.

In any case, all these resources talking about Staff Engineering are bullshit hype-cycle for a very simple reason: if you're a Staff Engineer, you know all this shit already. If you're not one, reading these books won't make you one. It's like thinking you can become a great woodworker by reading a book on woodworking. It's all just career voyeurism, or aspiration porn, written up to sound authoritative, but is actually completely made up, because it's actually just normal work that somebody wanted to sound more important.

> 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" maybe once a week. It is actually exhausting and frustrating to be in this position.

I can't talk too much about what I do, but I am a staff level platform engineer and run a platform that no one has heard of, and no one has used directly, but it affects most people reading this. Because of how important the security and infrastructure is, my job is to field requests all day long, say "no" to almost all of them, and accept 1-3 things a month that our team actually works on.

Saying "no" so often and being "the bad guy" that no one wants to give ideas to is frustrating and difficult. It is the hardest part of the job, far more than the technical component. I actually discuss it with my therapist nearly weekly, it takes that significant of a toll on me. I enjoy the core of the work, but these externalities of the job wear me thin and I often fantasize of going back to the time when I just showed up in a daily standup, took a ticket, and went away to work on it. Essentially what I am saying is "the grass is always greener", remember that.

Go for the startup. You will have more opportunity to shine. With 2 yoe, you will get held back at Big Tech. Even if you know your stuff, the yoe will always be held over your head. At a 20 person startup, you will shine and be given more opportunity. This will bolster your resume and maybe even divert your career in a new and exciting way.

Big tech isn't going anywhere. If you are getting offers from big tech now, you will later as well. I always tell people to start at smaller companies. They are way better when you are young because you will face a wider array of problems, which builds better experience. Big Tech is great when you are older. It is generally more focused, higher paying, better benefits, but can often be less rewarding.