The Staff Engineer's Path – Book Review

Graydon Hoare created Rust as a personal project while working at Mozilla Research in 2006 - https://en.wikipedia.org/wiki/Rust_(programming_language)

Not many devs create the core of what is arguably the best programming language available today as a personal project. However, it's true that what it has become today is now the work of many.

It's up for debate, but I would define "staff" as "here is a vaguely understood problem we believe has to be solved; find out what it is, whether it actually is a thing, why it happened, whether it is worth the time to solve, and finally guide others to solve it for us." It can get manager-like, but the lack of direct person oversight is distinct enough IMHO.

The creators of the software you mentioned are rarely in a role defined as such. If you really want to go the hard-core coding path, the startup scene is the best place to look.

> Your company might have a written definition of what good engineering means - written values, and engineering principles. But the clearest indicator of what the company values is what gets people promoted.

This is really the takeaway you should have. Be observant of what is actually rewarded. Companies are made of people. Unless you're in some ultra bureaucratic government position that is 100% impossible to get around - the guidelines are not really that important.

Instead, it's all about your relationship with your management chain. If your management chain likes you (the reason why doesn't matter) then that's all that really is important to your progress in your career. You can be more impactful than any employee, add to the bottom line of any business meaningfully, and still get fired because your management chain doesn't like you. And vice versa - seen folks do nothing to add to the bottom line or make any impact and yet - promos come their way.

Getting to staff and beyond is entirely about politics. It has little to do with your actual work. I'd highly recommend finding an organization that aligns to you. If you feel like an outsider in your company - switch companies until you find one where you feel accepted. If this is not possible (and it often enough isn't possible) - then ask if it's worth it and start wearing a costume and play whatever part you think will get you further. (Even with this attitude - it might still not be possible to advance. We live in a unjust world.)

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 don't spin off cool internal projects like this into startups. Hashicorp's market cap is roughly 10% of the market cap of the megacorp I used to work for. And right now, my team is working on an internal project to fill the gaps left by various authentication providers we use. But instead of spinning this off into it's own business, they are just kind of waiting around for someone else to develop a better product so they can buy it instead.

It was explained to me that investors generally don't like spinning off internal projects because it can be a distraction, but it does feel like investors are leaving a billion+ dollars on the table. Especially given the absurd P/E multiples software startups enjoy.

To circle this comment back, I think a lot of staff engineers are working on the next generation of cool technology right now. But they might be working at boring old companies, like a massive retailer, and eventually that internal project will get replaced by one built by the engineer who decides to venture on their own and replicate what they were building as a stand-alone product.

> 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 this one: Sometimes there are just really great ideas.

Minecraft comes to mind. And I don't mean today's Minecraft. I mean the alpha and beta versions which were wildly popular and essentially just an engine and sandbox world with a tiny fraction of the features today's game has. People have recreated that core game many times with fairly trivial code, which is why I attribute this more to "great idea" than long iterative process that most people cant replicate. And a totally anecdotally and subjective reason (although I've heard others express it too). I found the game immediately nostalgic. It was new but it felt old - like it had existed in some form before but had just now taken shape. That to me seems like a great idea.

Ironically, I find myself questioning if I underestimated how long Notch took to create it. A cursory search says a week for the initial version, but this timeline shows more like 1 to 1.5 years from nothing to alpha: https://minecraft-timeline.github.io/ Even still, the fact that the core game can be recreated without too much effort does suggest that that it was more about being a good idea than being difficult to implement. I don't look at Minecraft and think "wow I could never do this." Instead I look at it and think, "Wow. That was a really great idea."

Although I suppose you could says that great ideas are an iterative process too. But at that point you have to decouple "really impressive stuff" from "I could never do this".