Live data from Hacker News

The Staff Engineer's Path – Book Review

smyachenkov.com

161–170 of 251 posts

Re: The Staff Engineer's Path – Book Review

#161

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…

I have two Staff+ level positions open on my team. The expectation for them is to be able to work in a cloud-native (AWS/K8s/Terraform/etc), distributed systems (Kafka/SNS/SQS/Kinesis) that is mission critical because it touches people's money (fintech). And new client code gets written in modern stacks (Swift/SwiftUI, Kotlin/Compose, Typescript/React/Next.js).

If I were still an IC rather than a talking head on Zoom all-day, my role would map to somewhere between Senior Staff and Principal. I would write microservices from scratch, deploy to the cloud, operate them, and then write all of the clients (iOS/Android/Web) myself. I've been doing this for ~20 years so I have the ability to quickly pick up new languages, frameworks, platforms, technologies, etc.

The current Senior Staff/Principal engineers do projects like decomposing that old miscellaneous database from the original monolithic codebase and implement it across all domains with correct boundaries. Build libraries that all engineers on the team use. Ship V1 of that new product that is very strategically important to the company.

(Send me an email if you are a Staff+ engineer that is looking for something new!)

Re: The Staff Engineer's Path – Book Review

#162

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…

[dead]

Re: The Staff Engineer's Path – Book Review

#163

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…

Those jobs (where you create the next Redis) almost don’t exist. Instead you create something, toiling for years for no pay, and if it catches on you are set for life.

But HFT jobs might be interesting if you want to do hardcore engineering. I imagine there are a lot of interesting ML jobs.

Re: The Staff Engineer's Path – Book Review

#164

Earlier quoted context omitted.

When I worked at mega corps, I'd see a "new" tech emerged that was always very similar to a software that our company had developed to solve similar issues. I remember terraform getting released and seeing that it was just an inferior version of the Cloud Formation Template generator someone at my company had invented years prior. I've seen this happen so many times and every time, I'm surprised that more businesses…

There is a simple reason why megacorps don't spin off projects: they would need someone with vision to search for these projects and with high authority to proceed on the spin off. They don't have this kind of people, for the obvious reason that it is not their main concern. Executives in any megacorp are 100% busy making the core business a success, and investing time in small projects that may come to nothing is ju…

> They don't have this kind of people

Because the people with vision and conviction would be running their own startups

Re: The Staff Engineer's Path – Book Review

#165
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…

When I worked at mega corps, I'd see a "new" tech emerged that was always very similar to a software that our company had developed to solve similar issues. I remember terraform getting released and seeing that it was just an inferior version of the Cloud Formation Template generator someone at my company had invented years prior. I've seen this happen so many times and every time, I'm surprised that more businesses…

FWIW, the founder of HashiCorp created Vangrant when they are in college.

Why did Terraform end up being the dominant product? Product-market fit. That’s not just engineering, but bringing to market a product at the time when people need and understand it. This includes marketing and educating. Also, Terraform has an ecosystem of prebuilt providers. NPM as a package manager is not as well designed as other systems, but it’s arguably been the most successful. While the internal prop tech you mentioned may be more advanced, it’s not obvious you had the right product people with vision to build out that ecosystem. Most managers and product people at large companies aren’t tech savvy beyond buzzwords

Re: The Staff Engineer's Path – Book Review

#166
post #149

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.

Those can be some of the most fun problems. Fixing deeply rooted reliability or scalability problems in the business's core product without disrupting users? That's absolutely a path to recognition and rewards.

From personal experience: no it is not. This mentality leads to nothing but frustration and burnout as upper management sends you to tackle your "staff"-project.

Titles are all based on organizational politics and the macroeconomics at the moment. Were you hired during the 2021-2022 hiring spree where companies would give anything to keep engineers from getting poached? You probably were hired at Staff. If not, then what were you doing? Lol these folks were the first ones laid off.

Personally, I received my highest raises in 2021 and 2022. Multiple salary (and equity) bumps; a title bump. Life was fucking good.

Nowadays, you can just be glad not to get laid off. Instead of the promotion they promised, you get a slap in the face and some chump change.

I know I sound jaded but the fact that there are MULTIPLE books on "Staff"-level engineering (all un-ironically written by managers and executives rather than ICs) is completely laughable.

/rant

Re: The Staff Engineer's Path – Book Review

#167

Earlier quoted context omitted.

When I worked at mega corps, I'd see a "new" tech emerged that was always very similar to a software that our company had developed to solve similar issues. I remember terraform getting released and seeing that it was just an inferior version of the Cloud Formation Template generator someone at my company had invented years prior. I've seen this happen so many times and every time, I'm surprised that more businesses…

There is a simple reason why megacorps don't spin off projects: they would need someone with vision to search for these projects and with high authority to proceed on the spin off. They don't have this kind of people, for the obvious reason that it is not their main concern. Executives in any megacorp are 100% busy making the core business a success, and investing time in small projects that may come to nothing is ju…

Not just that they don't have those people. They also don't have the money. Because most companies are operating with someone else's money. It belongs to the shareholders or the investors or the bank. And they have been entrusted with that money in order to conduct a very particular business venture.

If they go off using that money to spin up side-hustles selling engineering tools, they're taking risks with someone else's money to do something they weren't told to do.

Re: The Staff Engineer's Path – Book Review

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

Because most questions are not bad questions. In isolation, if you have good teammates, ideas and questions are good. It’s just that you have to say “No” in the broader context, because you always have a limited budget of time and money

Re: The Staff Engineer's Path – Book Review

#169

My favorite version of Staff Engineer is "Person whose prospects for career advancement are limited by their seniority, who is consequentially incentivized to care about doing the right thing". Least favorite version is the one who doesn't realize this, and makes a muddle of an already working system to demonstrate their impact.

I've been on both sides of the latter case.

I think we should encourage "muddling" to the extent that it actually improves systems. However, usually such engineers underrate how difficult it is to actually improve said systems while maintaining legacy feature parity.

That is, the answer is not to discourage muddling, but to have higher standards for project management.

Re: The Staff Engineer's Path – Book Review

#170
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…

> Something I learned relatively late in my career was that really impressive work is the result of iterations in tiny steps. I think you are right. Really impressive work is generally the result of a longer journey than you realize. The time and effort put into it is probably underestimated. But my mind immediately tries to think of exceptions (which totally prove the rule). I'm curious if others would agree with th…

> like it had existed in some form before

I mean, it had. It was called Infiniminer. Admittedly it had only really existed for about a month before, but it was obvious that that first person voxel modification mechanic was a format that could support some really cool games. It got Notch thinking, for sure.

When Notch posted his first tech test video (archive version: https://www.youtube.com/watch?v=UMpv5kZ9-rE), he wrote:

> This is a very early test of an Infiniminer clone I'm working on. It will have more resource management and materials, if I ever get around to finishing it.

Ironically, he never did get around to finishing it.

Post reply on HN