15 ms·

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 doe

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 companies for people who love their craft and create software others can't. Most companies seem to be consumers instead of creators and only offer Jr.-to-Sr. level roles around making a CRUD API micro-service collection.

eatonphil 3y ago
One area to find great engineers (and interesting jobs) is at database, infrastructure and devtools companies. Places like Cockroach, PlanetScale, Docker, JetBrains, CodeWeavers, Fastly, etc. And the databases, infrastructure or tooling teams within Meta, Microsoft, etc.
- never_inline 3y ago
  Out of curiosity, do they have junior engineers too? I would love to work on docker or jetbrains for example.
  - eatonphil 3y ago
    Believe it or not these are all real companies that hire a variety of skill levels and even hire designers, frontend devs, support people, sales, marketing and so on. :) I mean not necessarily all of those companies are hiring all of those positions at every level this minute. But my point is that, you can almost always find some way into an interesting company such that you may be able to eventually pivot to (or at least periodically work with) a team you're interested in.
  - jacurtis 3y ago
    Both Docker and Jetbrains are working on software projects just like the rest of us. There is still boring shit work to do that no one else wants to do, so they need junior devs to shovel it off to. So yes, they have juniors, mid-levels, and everything up to staff and beyond. They are no different than any other company. The difference is probably that it is harder to get those jobs because everyone wants to work for the flashy exciting companies. I was considered for a job at Docker a long time ago (when I was an early-midlevel) and the recruiter told me that over 1,200 people applied in 5 days. For entry-level/intern positions I assume it is similar or even worse.
- Meszek 3y ago
  I'm at a point in my career when I need to decide if I want to work for European branch of American Big Tech or try a 20 people database startup (got offers from both). I've got 2 yoe in high performance c++, working on data processing engines. I'm really tempted to go to the startup... But big tech pays more. And I feel like I could actually learn how to use tools properly before I come back to writing them. Any opinions?
  - eatonphil 3y ago
    That's a really personal decision but if you want to send more details I'm happy to give a more thoughtful response. My email is in my bio.
  - reasonabl_human 3y ago
    ‘Big Tech’ will always be there in some form down the road. If you have the risk tolerance and early career flexibility, take the path less traveled.
  - sukki07 3y ago
    Based on your experience looks like startup is a good match. The argument about learning the tools first doesn't sound that convincing to me , it is mostly you justifying the high salary. Also database is not a tool per se and even if it is you will mostly understand how to query it , which is just like learning SQL and I don't think it will help you in writing a database
  - esafak 3y ago
    If you have never worked for a reputable big tech company, I'd do a brief stint for signaling, networking, and mentorship purposes. Then go to a rising startup.
  - jacurtis 3y ago
    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.
pc86 3y ago
> Most companies seem to be consumers instead of creators and only offer Jr.-to-Sr. level roles around making a CRUD API micro-service collection. That's because this is what 90% of companies need. 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.
- feoren 3y ago
  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 software badly. The gap between what software could be vs. what it is is so overwhelmingly massive that it's crushing my soul. 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.
  - pc86 3y ago
    You're right, they'd pay probably 25% more in payroll, get a lot less done in terms of features businesses need (compared to neat tech stuff we devs want to build), and the business would eventually go bankrupt.
  - ZephyrBlu 3y ago
    > 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 are good at solving complex problems that many other developers combined could not solve. They are not good at writing 10x more LOC than other developers.
losteric 3y ago
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.
- Xeoncross 3y ago
  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?
  - amf12 3y ago
    I'd say it's a bit of both. You can build yourself up and find such work in companies which have it. Not switching employers very frequently helps, because building credibility takes time. After you've built up credibility in some interesting tech, other companies would find you based on your work. This is just my observation, so take it with a grain of salt
  - aardvark179 3y ago
    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.
UncleMeat 3y ago
Software engineering. Most engineering is this way. Somebody needs to build a thing that isn't too different from other things on a budget and a timeline. Your typical civil engineer isn't designing a new burj khalifa. Most software engineering is about organizing a group of people to build a thing for a customer that isn't too different from other things, on time and on budget. There just simply aren't as many jobs working on wild stuff nobody has ever done before. RollerCoaster Tycoon is, in my opinion, a great example of something that isn't really engineering. One person did it and the decision to write it all in assembly is almost anti-engineering. It is an impressive feat, but not really comparable.
- Xeoncross 3y ago
  So are we saying that software engineering can be at odds with your ability to write code? I'm not sure most people would say they are quite the dichotomy you present here. While I agree it's often a team-sport, being able to create amazing things yourself (i.e. Git, Redis, RollerCoaster Tycoon, Rust and other single-person projects) that others struggle to replicate or contribute too shouldn't mean you're a bad software engineer.
  - UncleMeat 3y ago
    Not quite. I am saying that there is a meaningful difference between the process of working with other people over time and with resource constraints and writing software alone without time or resource constraints. Being skilled at writing programs doesn't harm one's ability to make decisions according to engineering principles. I actually don't know for certain that writing Rollercoaster Tycoon in assembly was the not only possible way of doing it. But in popular consciousness it is usually discussed as a wildly difficult thing rather than the most efficient solution to a problem. That's anti-engineering. There isn't really a good set of words to break down categorization. But I do think that the skills involved in the large majority of software engineering roles are pretty much entirely separate from the skills involved in writing some exceptionally difficult program.
    - mattbrewsbytes 3y ago
deleted 3y ago
[deleted]
HEmanZ 3y ago
It’s always odd to me people ask this, because you see it all the time if you work on big infra. It just goes to show my experience at mostly infrastructure at big tech is just not normal. Anywhere there are extremely large or technical company will have stellar ICs. All the FAANG have them (not everyone working there is one, but they are around and you find a lot of them on e.g massive distributed data systems). Not only do you run into stellar staff engineers at these places, but if you work on critical infra at say Google, you run into a couple 50x engineers that defy classification. Any company that produces a world-class database, distributed system, etc. will have very good, very expensive staff engineers, who really are ICs and not managers.
markus_zhang 3y ago
Yeah I'm wondering the same. I have always been looking forward to doing something fundamental and those people are the ones I look up to.
mkozlows 3y ago
The idea is that staff+ engineers can drive high-complexity work, right. There are arguably two types of that work: 1. Work where no individual component is complex, but there are a ton of moving parts and interlocking dependencies and interacting systems and so forth. A staff+ engineer is needed to drive this, but that job is less about writing the hard code and more about teasing out and resolving the hard interactions, so that kind of system design 'n' people role. 2. Work where there is a self-contained component that is very complex. A staff+ engineer is great to drive this, and may do so by writing the code themselves and reviewing other people's code as a developer. In practice, many more companies have complex distributed systems than complex contained systems, but certainly both kinds exist.
rubiquity 3y ago
In my experience these people are usually in the types of environments that most engineers hate to work in. Environments completely void of the creature comforts we're used to for solving the task at hand because they are working in a new domain that likely needs new abstractions. Tools and libraries such as testing, build, automation, data structures, concurrency, fundamental primitives etc. that are suitable and at the right level of abstraction for the task at hand. Really bad engineers see these environments and complain without doing anything about it, ultimately leaving the project. Slightly better engineers complain about the tools and blaze ahead anyway leaving a mess in their wake. The great ones I've been so lucky to work with pave the way on those fronts at the same time as solving the problem at hand and make it easier for their successors. It's quite beautiful when you see it.
PartiallyTyped 3y ago
I am an engineer that got shoved into this role shortly after graduating with an MSc by being the most knowledgeable person for this project. I am by no means a rockstar in any particular field of software engineering, but I have worked on a very wide gamut of projects. This enabled me to dissect the task into the constituent parts in an attempt to reduce uncertainty and complexity. Fwiw, I have no life, severe executive dysfunction that doesn’t allow me to stop thinking about what I am working on, and an abundance of curiosity.
lhorie 3y ago
Big tech companies have entire departments dedicated to this sort of engineering, usually developer platform/experience/productivity, or other similar infra/platform orgs. I'm an author of an open source framework who got scouted to work at one (and I'm currently a staff eng). IME, yes there's comparatively far more CRUD roles than platform roles. But bluntly speaking as someone who's been on both sides of the fence, platform roles are not for everyone. For these roles, there is a expectation of quality by very technical stakeholders and this creates some pressures and incentives that don't necessarily exist in orgs that cater to non-technical faceless stakeholders. In practice, a big challenge is to avoid being someone who is "not hardcore enough" (i.e. incapable of implementing large scale reusability due to lack of ability, tendency to cave to timeline or other pressures, or distaste for "office politics") but also avoid being "too hardcore" and being constantly in the weeds chasing some cool clever idea that might not align w/ overall picture. One thing that is often overlooked in open source projects with sizable communities is the amount of cat herding you need to do. People have all sorts of ideas for "features and improvements" and 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.
- jacurtis 3y ago
  > 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.
skeeter2020 3y ago
staff and principal engineerings are still leaders who spend an awful lot of their time coaching and mentoring, they probably just don't have direct people management responsibilities. There are very few situations that will give you an advanced IC title for doing stuff that "no one else can do" because of one word: leverage. It's not economic (in all but the rarest, most specialize cases) for me to say "I want 10x developers who are snowflakes" vs. "I want my senior engineers to increase their sphere of influence and make every developer fractionally better". It's very hard for a senior developer to increase their skills 10% YoY, but actually pretty easy for them to help 20+ developers get 1% better. Staff and Principal developers go deep on the leadership aspects (I shudder to say architecture, but it is the "good" parts of this) and very, very wide on their application & influence. As a result the opportunities for deep engineering work are more like mining than farming. I manage 2 core teams, one a "platform" team made up of all senior => principal engineers, and they spend a lot of their time shepparding other less experienced teams while trying to answer very tough, vague questions like "what bottlenecks do we predict at 10x scale? What can we opportunistically do today?". No one gets huge, dedicated time blocks to code without some degree of accountability and expectation.
PhilipRoman 3y ago
The list you named is a bit strange, I wouldn't put something like docker anywhere near the others, their innovation isn't really on the technical side. If I had to take a guess, a lot of these places are close to hardware. Working with hardware has the additional bonus of often mandating high performance. Any task becomes a lot more exciting when you have microsecond deadlines for controlling an industrial laser.
stagger87 3y ago
I work in an EE dominated industry where staff and principal titles are only handed out to 30+ year veterans who know their domains better than anyone else in the world. These are people who specialized in one thing their entire career (mmWave RF amplifiers for instance). These companies are every where big software is at, and then some. They don't pay great, they are not "cool" to work at. Gov is often the biggest customer. Doing something novel in these fields will require a PhD, a decade of corporate R&D experience, and significant corporate backing.
- esafak 3y ago
  Everything about this is why people rightly go into software instead.
mathgladiator 3y ago
You're seeing a variant of Price's Law ( https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price) Big tech sucks a lot, and I mean a lot, of the oxygen out the market for these roles. If you take the total population of engineers, then how many engineers are needed to build TCP/IP stacks, new app network protocols (i.e. QUIC), databases, web frameworks? The unfortunate truth is that getting deep experience is rare. Risk aversion is a core culprit; would you trust a tech not supported by a large community? This creates a tremendous market pressure on a handful of players. This is one of the reasons that I had to work at big tech to get the experience and skills that I wanted. For example, when I was at AWS, I read every COE (cause of error) report for the big services. This helped me tremendously both as an IC and leader. Now, I hate that I had to bend the knee to big tech...
simonw 3y ago
> I've been bothered by the fact that most advanced engineering roles like "staff" actually mean "manager who does system design as well" The definition I have generally seen for "staff engineer" is an engineering leadership position without direct reports - I see "manager" as generally meaning "has direct reports". I think this is important: leadership and management are not the same things!
- etamponi 3y ago
  Can you explain better the difference? I am trying to figure this out myself for a while...
  - rokob 3y ago
    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. Engineering management is more on the management of people and engineer leadership is more on the management of products/projects/systems.
    - deprecative 3y ago
      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.
      - joshuamorton 3y ago
        Ehh, I am employed at a company where, despite things being very tense at the moment, I've felt very comfortable expressing to my manager my intent to transfer out of the team I'm currently on and into a different position, as I'm not happy with things as they are. My manager, skip, and director have all been extremely supportive of this throughout the process, despite it taking a somewhat lengthy period of time and putting me (a senior-almost staff eng on the team) in a position where it's very difficult for me to commit to a significant ownership of big strategic things (which is my job) since I might transfer out at any moment. Similarly, a few years back, I expressed intent to transfer away from my team to my manager. He basically said "stick around an extra quarter since you're on the cusp of promotion and it'll be easier this way" (and he was correct, my promotion would have been delayed if I transferred first), and I did and got promoted, and ended up staying longer, for various reasons. Additionally, my managers have all been receptive to my goals in terms of career growth: do I want to lean into management (no!) or into deep technical expertise? Do I want to go for additional promotions, or am I happy to stay in the role I'm in and continue doing the same kind of work? All of this, to me, reads more like career management than job management.
SimonPStevens 3y ago
> Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? They create their own thing from scratch, and turn it into a job. The first 5 from that list were open source creations that became big because they met a need at the time and lots of people adopted them. Which is one route into creating your own thing. I've seen senior engineers who have leveraged lots of domain knowledge to build a prototype of something super useful internally within a company that then grows in adoption and size as people recognise it's value. Projects then start to organically cluster around the core that was built solo.
onion2k 3y ago
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 a special title for people who make amazing things. They're not that different to the rest of us. The main thing they have going for them is an environment that lets them shine - time to research and explore, less pressure to do things that aren't moving them towards the end result we see, and fewer externalities that make them lose focus. I'm not suggesting just anyone could make Linux or Roller Coaster Tycoon, but I am definitely of the opinion that given then right circumstances most people could produce something that other people believe is at that sort of level of complexity. May we all find those jobs one day.
- mywittyname 3y ago
  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.
groby_b 3y ago
They exist, and they aren't that rare. My org currently has a noticeable percentage of staff+ ICs, not managing, and I'm actively encouraging folks to think careful if they really want management. I am far from the only manager doing that. But yes, jobs are very rare. Staff+ ICs tend to like to stay where they work (because great achievements take time), there's only a limited number of roles, and a lot of this is word-of-mouth in a given field. I'd look either at FAANG - they're large enough to always need staff+ folk - or startups once they have round A. They live or die by having really experienced and productive staff+ folks, and they're large enough that they can offer staff+ interesting challenges. Why not pre-founding? At that point, any good staff engineer I know is driven enough that they'd be better off just starting their own. In a small startup, the founder is either technical and interested in solving the hard questions, or non-technical and you'll have essentially a CTO role, but without founder credit. It's not a hard-and-fast rule, there are exceptions to everything - but that's where I'd focus my search if I were to search for that kind of role.
brianm 3y ago
Most companies, in my experience, don't actually know how to make use of Staff+ engineers. I spent years at a medium sized public "tech" company just trying to help the company change engineering enough to make use of these folks, and we go to a place where we could... mostly. FANG and FANG-model (anyone copying FANG engineering/product model) companies do it well and have the bulk of success cases. Look for engineering-lead companies first, product lead companies second. A key question when interviewing is "how is the roadmap established?" You want answers where senior leadership establishes goals (strategic or metric), product provides their understanding of opportunities, and engineering decides what to actually do. Even then, there will be the common failure model of EMs doing the roadmapping, not senior (staff+) ICs, but you can tease apart how that works, as it is always going to be a mix.
- feoren 3y ago
  > Most companies, in my experience, don't actually know how to make use of Staff+ engineers. Absolutely spot on. Making use of Staff+ engineers requires giving them a hard problem that would catapult your company forward if it were solved, and a ton of autonomy in how they go about it. Give them dedicated time to prepare presentations on what they're doing and what they've learned recently. Give them dedicated time to mentor other staff members. Give them a routine, but not a schedule. Stop asking them for so many fucking estimates. Give them access to support staff. And then get your fucking hands off them and let them veritably radiate value to your company. All of this is, of course, antithetical to whichever imposter-syndrome micro-managing MBA vice president happens to have landed in the chair that gives them authority over these people in their never-ending game of Management Musical Chairs. No fucking way are they going to let some grunt just work on a hard problem without constantly getting in their way, nagging them about pointless deadlines and bullshit estimates, and showing visual progress via good-looking DOM elements so they can take credit for it and get Business Points before their 2-year tenure in that chair is up and they move to Head of Brand Awareness or wherever. No: doing so would reveal that their entire position is literally pointless. Can't have that.
lifeisstillgood 3y ago
This is the hidden side of staff engineer. The bit books don't get written about for the same reason "how I got rich" books leave out the people who worked hard but got less. Somewhere someone has to have the time to build out the tools, then dig the foundations and lay the scaffolding and the supporting walls. None of which looks like the artists impression and none of which has a web interface you can show. So Staff engineer is like architect. Holding the nervous customers hand while they spend a fortune to have a large hole in the ground. You cannot build a bridge by stacking bricks in front of the customers feet one at a time in a nice iterative process. You cannot always "see" progress at the user level. to me the signature of really good software is when one marginal change delivers outstanding value and the engineers just say "was that it".
NBJack 3y ago
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.
- feoren 3y ago
  > 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." I would define that as "software engineering". What else are any of us doing all day? The compiler's job?
  - jmchuster 3y ago
    It's the scale of it. "Here is a vaguely understood problem, that might take 2 hours to solve." "Here is a vaguely understood problem, that might take 2 years to solve." Though if you're used to the latter timescale, you might not consider the former as all that "vaguely" understood.
guhcampos 3y ago
My single tip is: look for Product companies, not Service/Project companies. This means looking for companies who build and maintain a product, SaaS or not, which they offer to customers, and avoid all sorts of consulting, offshoring, nearshoring, whatevershoring third-parties. Project/Service companies draw little value from engineer familiarity with the systems they work on. Contracts and projects come and go, and everyone needs to learn new systems, processes, and technologies all the time. Experienced people end up as Project managers because that's the only path to career growth. Product companies, on the other hand, suffer a lot from engineering turn-over, since they have this one complex system they need to babysit forever, and ever time someone leaves, the accumulated knowledge built on that person leaves with them (likely to a competitor who really benefits from that knowledge as well).
- feoren 3y ago
  As someone who has worked at a "Project/Service" company for way too long, I wholeheartedly agree. It's a horrible way to build software and will drain your soul. Good software is both much more expensive and much more valuable than most people realize, and one contract or client is never enough to give it the attention it deserves. Your clients will wonder why your $200k custom software doesn't work like Excel / PowerBI / some other product with tens or hundreds of millions of dollars of investment. It will wear on you that you simply can't give your software the love it deserves solely on the tab of one single client.
coev 3y ago
Doug Crockford was "Distinguished Fellow Engineer" or some title like that at Paypal.
kimixa 3y ago
The only time I've seen anyone really do half of what this books describes as a "Staff Engineer" was at a small(ish) hardware company, PowerVR, where the OpenGLES driver team was 5-6 people, the team lead was a developer and architect who also did a bit of management, rather than the other way round. Then there was a manager on top of them in turn for multiple teams, but they weren't involved in the technicals at all, not even in the loosest "architecture design" ways, they purely did the people management. In a larger company now, still working on GPU drivers (AMD, but not the "main" platform), there's a couple of people who might do a bit of this, but feels more like you get specific domain experts rather than anyone designated by the company. The team is notably larger than at PowerVR, and there is a "Manager" who is more involved in doing things like placating customers and prioritizing work and issues, but again completely uninvolved in the actual development. In none of these examples does the job title have any relation to the differences in their work, both used completely different stacks of terms and difficult to compare cross-company. But I guess it's all "Hardcore Engineering", and even the newest members of the team are expected to design systems themselves. Hell, straight out of university at PowerVR I was designing and implementing my own stuff, and significant systems not just following an already concrete architecture. But it was a small enough team everyone was involved in feedback, and I did feedback to them in turn. So I guess GPU drivers are still greaybeard "Hardcore Engineering"? This may be helped by driver development often being pretty well defined, you have a spec (which you may have been involved with designing, but very much a large collaboration), you have hardware architects and another team trying to figure out the next generation might look (are they the "true" architects here?).
coliveira 3y ago
> Where do all the hardcore engineering jobs live There is NO such thing as hardcore engineer job position that doesn't involve a lot of management. All the good engineers that get jobs are the ones who do management work as well as coding. If you cannot do this, the industry will just close its doors for you.
- trgn 3y ago
  > There is NO such thing as hardcore engineer job position that doesn't involve a lot of management So bizar. I've been in a few companies with senior "hardcore" engineers heads down in code, without management responsibilities. > If you cannot do this, the industry will just close its doors for you. Wait what? A good engineering company will strive for a mix of seniority within teams of ICs. Some of these seniors may become "staff", which usually means, can talk tech stuff to the brass.
  - coliveira 3y ago
    It only changes the kind of management responsibilities you're talking about. Yes, some positions will have zero employee management, however you'll be responsible for product management. There is no product in a big company that can be created with zero collaboration, so you'll be responsible for managing collaboration with other groups, determining features and getting ok from management, making sure that others are doing their work, etc. It is management nonetheless, sometimes with lots of meetings, just with a different goal.
  - throwway120385 3y ago
    Most companies are not "good" engineering companies. They are at best mediocre.
- proc0 3y ago
  In my opinion this is a big reason software is so brittle, needs to be constantly patched and updated, and overall innovation in software moves very slowly. Having engineers do management work is undermining how hard engineering is -OR- underestimating how powerful software is. In other words, the Idea is that engineers adds more value to a company if they also do all these management tasks, which implies that engineering is not enough and is not as valuable on its own - something I would contend because as we can see software is capable of amazing things like AI that will soon automate all these management tasks anyway. If companies invested in their engineers doing only engineering, then people could maximize their skills, and reach those new levels of productivity thanks to advanced software. Instead the industry limits engineers, and insists on them hitting a technical ceiling, effectively pushing them in a non-technical direction in favor of hiring younger engineers to do the "grunt work". Software engineering is only grunt work when you don't understand its true potential, and its endless complexity that takes a lifetime to master.
bippihippi1 3y ago
smaller companies, and new teams in larger orgs. if you work on an existing system there's less 'interesting' work and more iterative improvement. larger orgs can produce hardcore stuff, it's just usually too large to attribute all of the 'interesting' stuff to one person. a microservice is just a library with infrastructure, not that much different from writing a small part of a 'hardcore' project. also you can start your own project and do something amazing
personjerry 3y ago
At big companies there are high level IC roles, supposedly "mirroring" the manager levels, for people who are the "creators" and effect change in tech on a large scale without people management. For example I remember at Facebook I attended a "class" on keyboard shortcuts, taught by one of the creators of a *nix utility (I forget which)
VirusNewbie 3y ago
I've worked at a big telco and now FAANG and I can tell you there is so much non CRUD work it's crazy. There are very very hard technical problems to solve in FAANG.
leothecool 3y ago
We're all out here chilling in the midwest working at lifestyle businesses.
alistairSH 3y ago
Depending on the company, this could also be a senior architect, technical fellow, or something similar. Or just an engineering manager or tech lead. It's hard to know from the outside exactly what each role really means. My employer has Technical Fellow at the top of the architect job family. It's equivalent to a director or senior director in seniority, but remains an individual contributor. These are the people creating (or more accurately, enabling the creation of) the really amazing software here. But, given the business we're in, the software they build is never going to enter the common lexicon like Uber or Google or whatever. And I'm a little confused by your "most companies are consumers" comment. Sure, in a literal sense, most software projects are built using tools written by somebody else. If you want to be building those tools, you need to get a job at someplace that builds tools (which usually means proving yourself an expert in a particular niche/tool/whatever). But, there's plenty of software between "simple CRUD" and "creators the next [impactful tool or infrastructure]"
agentultra 3y ago
You could read the main linux kernel git log and see who the top contributors are. If you prefer system level programming there are jobs out there and plenty of work to do. I dunno if this counts as, "hardcore engineering." To me, engineering, involves many other skills other than writing code: being able to specify systems clearly and, as the occasion demands, formally is a part of engineering; communicating with others; Knowing which trade offs to make depending on a situation, etc.
rmk 3y ago
There aren't too many hardcore engineering jobs. They are being done in startups where hard problems are being solved, and even there the average startup is just a website which is acting as a broker in a two-sided marketplace, or some variant thereof. If you step back and think about it, it makes sense. The majority of companies are one-trick ponies, maybe following up with a few additional products. Incremental development is the path of least risk once product-to-market fit in a large market with high growth is achieved. As public companies (and late-stage startups or private companies) are incentivized to reduce risk, the majority of the people will be doing incremental work. The growth of the pseudo-technical managerial class in the form of Product Managers, Project Managers, and umpteen levels of mid-level managers further encourages the relative lack of 'hardcore engineering'.
- jameshart 3y ago
  Why do so many people in the tech industry have so little respect for their peers who work elsewhere in the industry? The idea that large companies aren't solving hard problems, that that's only being done at startups, and that large companies are 'one trick ponies' is just incredibly myopic. Have you worked at a large publicly traded tech company? Sure, in any business a bunch of the systems will be trivial. In larger businesses - especially ones that have grown through acquisition - there's also some scaling-law complexity that means they have to also do a bunch of annoyingly trivial work gluing together lots of duplicative and redundant trivial systems. When you look in from the outside of a large business that mess can definitely obscure the fact that at the heart that stuff is all in support of, usually, several significant and impressive engineering achievements, which support and drive that business forward. And they're probably performing operations that, from the outside, you would hear the name of and think 'well, that doesn't sound very difficult'. I'm going to give a non-software example, that I think might show a little bit of an analogy for how 'engineering' at big companies can be at the same time operating at a complexity you wouldn't imagine, and yet be accomplishing something you might think from the outside is totally trivial. Jump to this timestamp in the recent Smarter Everyday video about Kodak's film manufacturing line: https://youtu.be/mrJP82ZZiag?t=1742 https://youtu.be/mrJP82ZZiag?t=1742 See that workshop? Those precision engineered toolheads they call 'hearts' are the punch+die sets that they use to cut sprocket-holes in film. Everything there is bespoke, custom-made, and meets constraints you would never have thought of. It's engineered. Software engineering in large companies is like that. If you don't think that banks contain software systems as complex and carefully engineered as those hearts? Or that manufacturing control software isn't in the same league? Or that the inventory management systems that drive a large retail business aren't on that level? You just have no idea what engineering is.
zerr 3y ago
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.
opportune 3y ago
I know people like this, I work on major public cloud products. Sometimes they are “staff” or other high level-titled. But you have to recognize some of the projects you’ve listed are mostly notable because they are very well documented and have a lot of OSS (besides RTC) mindshare; there are just as technically challenging and valuable projects that are less well known because they are proprietary sold software.
greenthrow 3y ago
Have you read the book in question? The whole point of it is that it is not a manager position.
MobiusHorizons 3y ago
What you are talking about are engineering investments. Generally you have to make the case for those. Management will generally not want to make those, because they are costly, and require long term maintenance. You have to prove that it will be good for business somehow. No one gives this to you, you fight for it, or build it without asking
trelane 3y ago
> Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? Unless they're very fortunate, they're wishing they could do the groundbreaking stuff that's in their bones, whilst they get ordered to ignore it, to other stuff that's higher immediate priority. So they do the needful while tinkering as they can find time to. > Where are the people creating amazing software and do they get a special "advanced developer" title? No, they get no special title. They just get ignored, unless they get lucky and find a manager that supports them.
YesBox 3y ago
>Where are the roller-coaster tycoon creators? Hello! I'm making a roller-coaster tycoon inspired game, in the form of a city builder. I ended up creating my own path finding algorithm that 10x's the performance of A*. I felt this would be useful since pathfinding is one of the major slowdowns of simulation games. https://twitter.com/YesboxStudios/status/1647224184597102592 https://twitter.com/YesboxStudios/status/1647224184597102592
closeparen 3y ago
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 set up to socialize it out of younger engineers and to have an immune system to reject any more senior engineers who endorse it.
- inimino 3y ago
  And the stronger this rejection, the stronger the pressure on anyone who represents a counterexample to the dogma to leave.
  - closeparen 3y ago
    Strong coders are usually pressed into technical leadership roles where they don’t have much time to code. It’s true that if you shirk your non-coding duties you’ll get managed out.
pkaler 3y ago
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!)
tourgen 3y ago
[dead]
quickthrower2 3y ago
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.
urthor 3y ago
Research. End of the day, everyone at Bell Labs was a researcher with a PhD. Engineering, bringing research to people, trends to CRUD over time.
jldugger 3y ago
> 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 traveling between big tech companies but mostly as a prestige recruiting / consulting role. Or Torvalds, whose finances I don't really understand -- multiple sources say he gets a million dollar salary from the linux foundation? You might also argue that the people who put more value on their skills as "hardcore engineer" end up in small firms and startups where equity comp can end up paying them what they're worth if the skills pan out. There was a "why is Google behind openAI even though they published the transformers paper" post recently that hinted that all the authors have left google for greener pastures, which supports this thesis. [1] https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e88a8 https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...
- jameshart 3y ago
  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).
ww520 3y ago
At staff and principle level, the job becomes mentoring and working with other senior people under you. There might be a business need/problem, and you have the vision to address it. You gather the requirements, do feasibility studies, evaluate the technologies, nail down the architecture, design the components, and work closely with other senior engineers on the prototype/design/implementation. You might code up the prototype and proof of concept during the exploratory phase. You might code up couple components you believe you're the expert in doing it. At the end of the day, you're the voice and the advocate to ensure your end-to-end vision is implemented.
facet1ous 3y ago
There are a few "hardcore" staff/prinicpal engineers at my company (a well known tech unicorn). They are basically OGs who were a big part of the company's early success. Really smart and saavy guys who are left alone to focus on executing on big stuff. The reality for other staff engineers here is exactly opposite though - you're not allowed to just be "executing" and your day consists of being stuck in meetings, doc writing, and management-lite. Honestly it's so bureaucratic and so far removed from the actual tech I really got turned off from that career path as I got more visibility into it. For smaller companies it's probably much more fulfilling though.
SergeAx 3y ago
The exact idea of the Stuff Engineer is that they are not managers. They are leaders though, it is a different matter.

eatonphil 3y ago

One area to find great engineers (and interesting jobs) is at database, infrastructure and devtools companies. Places like Cockroach, PlanetScale, Docker, JetBrains, CodeWeavers, Fastly, etc. And the databases, infrastructure or tooling teams within Meta, Microsoft, etc.

never_inline 3y ago
Out of curiosity, do they have junior engineers too? I would love to work on docker or jetbrains for example.
- eatonphil 3y ago
  Believe it or not these are all real companies that hire a variety of skill levels and even hire designers, frontend devs, support people, sales, marketing and so on. :) I mean not necessarily all of those companies are hiring all of those positions at every level this minute. But my point is that, you can almost always find some way into an interesting company such that you may be able to eventually pivot to (or at least periodically work with) a team you're interested in.
- jacurtis 3y ago
  Both Docker and Jetbrains are working on software projects just like the rest of us. There is still boring shit work to do that no one else wants to do, so they need junior devs to shovel it off to. So yes, they have juniors, mid-levels, and everything up to staff and beyond. They are no different than any other company. The difference is probably that it is harder to get those jobs because everyone wants to work for the flashy exciting companies. I was considered for a job at Docker a long time ago (when I was an early-midlevel) and the recruiter told me that over 1,200 people applied in 5 days. For entry-level/intern positions I assume it is similar or even worse.
Meszek 3y ago
I'm at a point in my career when I need to decide if I want to work for European branch of American Big Tech or try a 20 people database startup (got offers from both). I've got 2 yoe in high performance c++, working on data processing engines. I'm really tempted to go to the startup... But big tech pays more. And I feel like I could actually learn how to use tools properly before I come back to writing them. Any opinions?
- eatonphil 3y ago
  That's a really personal decision but if you want to send more details I'm happy to give a more thoughtful response. My email is in my bio.
- reasonabl_human 3y ago
  ‘Big Tech’ will always be there in some form down the road. If you have the risk tolerance and early career flexibility, take the path less traveled.
- sukki07 3y ago
  Based on your experience looks like startup is a good match. The argument about learning the tools first doesn't sound that convincing to me , it is mostly you justifying the high salary. Also database is not a tool per se and even if it is you will mostly understand how to query it , which is just like learning SQL and I don't think it will help you in writing a database
- esafak 3y ago
  If you have never worked for a reputable big tech company, I'd do a brief stint for signaling, networking, and mentorship purposes. Then go to a rising startup.
- jacurtis 3y ago
  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.

pc86 3y ago

> Most companies seem to be consumers instead of creators and only offer Jr.-to-Sr. level roles around making a CRUD API micro-service collection. That's because this is what 90% of companies need. 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.

feoren 3y ago
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 software badly. The gap between what software could be vs. what it is is so overwhelmingly massive that it's crushing my soul. 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.
- pc86 3y ago
  You're right, they'd pay probably 25% more in payroll, get a lot less done in terms of features businesses need (compared to neat tech stuff we devs want to build), and the business would eventually go bankrupt.
- ZephyrBlu 3y ago
  > 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 are good at solving complex problems that many other developers combined could not solve. They are not good at writing 10x more LOC than other developers.

losteric 3y ago

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.

Xeoncross 3y ago
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?
- amf12 3y ago
  I'd say it's a bit of both. You can build yourself up and find such work in companies which have it. Not switching employers very frequently helps, because building credibility takes time. After you've built up credibility in some interesting tech, other companies would find you based on your work. This is just my observation, so take it with a grain of salt
- aardvark179 3y ago
  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.

UncleMeat 3y ago

Software engineering. Most engineering is this way. Somebody needs to build a thing that isn't too different from other things on a budget and a timeline. Your typical civil engineer isn't designing a new burj khalifa. Most software engineering is about organizing a group of people to build a thing for a customer that isn't too different from other things, on time and on budget. There just simply aren't as many jobs working on wild stuff nobody has ever done before. RollerCoaster Tycoon is, in my opinion, a great example of something that isn't really engineering. One person did it and the decision to write it all in assembly is almost anti-engineering. It is an impressive feat, but not really comparable.

Xeoncross 3y ago
So are we saying that software engineering can be at odds with your ability to write code? I'm not sure most people would say they are quite the dichotomy you present here. While I agree it's often a team-sport, being able to create amazing things yourself (i.e. Git, Redis, RollerCoaster Tycoon, Rust and other single-person projects) that others struggle to replicate or contribute too shouldn't mean you're a bad software engineer.
- UncleMeat 3y ago
  Not quite. I am saying that there is a meaningful difference between the process of working with other people over time and with resource constraints and writing software alone without time or resource constraints. Being skilled at writing programs doesn't harm one's ability to make decisions according to engineering principles. I actually don't know for certain that writing Rollercoaster Tycoon in assembly was the not only possible way of doing it. But in popular consciousness it is usually discussed as a wildly difficult thing rather than the most efficient solution to a problem. That's anti-engineering. There isn't really a good set of words to break down categorization. But I do think that the skills involved in the large majority of software engineering roles are pretty much entirely separate from the skills involved in writing some exceptionally difficult program.
  - mattbrewsbytes 3y ago

deleted 3y ago

[deleted]

HEmanZ 3y ago

It’s always odd to me people ask this, because you see it all the time if you work on big infra. It just goes to show my experience at mostly infrastructure at big tech is just not normal. Anywhere there are extremely large or technical company will have stellar ICs. All the FAANG have them (not everyone working there is one, but they are around and you find a lot of them on e.g massive distributed data systems). Not only do you run into stellar staff engineers at these places, but if you work on critical infra at say Google, you run into a couple 50x engineers that defy classification. Any company that produces a world-class database, distributed system, etc. will have very good, very expensive staff engineers, who really are ICs and not managers.

markus_zhang 3y ago

Yeah I'm wondering the same. I have always been looking forward to doing something fundamental and those people are the ones I look up to.

mkozlows 3y ago

The idea is that staff+ engineers can drive high-complexity work, right. There are arguably two types of that work: 1. Work where no individual component is complex, but there are a ton of moving parts and interlocking dependencies and interacting systems and so forth. A staff+ engineer is needed to drive this, but that job is less about writing the hard code and more about teasing out and resolving the hard interactions, so that kind of system design 'n' people role. 2. Work where there is a self-contained component that is very complex. A staff+ engineer is great to drive this, and may do so by writing the code themselves and reviewing other people's code as a developer. In practice, many more companies have complex distributed systems than complex contained systems, but certainly both kinds exist.

rubiquity 3y ago

In my experience these people are usually in the types of environments that most engineers hate to work in. Environments completely void of the creature comforts we're used to for solving the task at hand because they are working in a new domain that likely needs new abstractions. Tools and libraries such as testing, build, automation, data structures, concurrency, fundamental primitives etc. that are suitable and at the right level of abstraction for the task at hand. Really bad engineers see these environments and complain without doing anything about it, ultimately leaving the project. Slightly better engineers complain about the tools and blaze ahead anyway leaving a mess in their wake. The great ones I've been so lucky to work with pave the way on those fronts at the same time as solving the problem at hand and make it easier for their successors. It's quite beautiful when you see it.

PartiallyTyped 3y ago

I am an engineer that got shoved into this role shortly after graduating with an MSc by being the most knowledgeable person for this project. I am by no means a rockstar in any particular field of software engineering, but I have worked on a very wide gamut of projects. This enabled me to dissect the task into the constituent parts in an attempt to reduce uncertainty and complexity. Fwiw, I have no life, severe executive dysfunction that doesn’t allow me to stop thinking about what I am working on, and an abundance of curiosity.

lhorie 3y ago

Big tech companies have entire departments dedicated to this sort of engineering, usually developer platform/experience/productivity, or other similar infra/platform orgs. I'm an author of an open source framework who got scouted to work at one (and I'm currently a staff eng). IME, yes there's comparatively far more CRUD roles than platform roles. But bluntly speaking as someone who's been on both sides of the fence, platform roles are not for everyone. For these roles, there is a expectation of quality by very technical stakeholders and this creates some pressures and incentives that don't necessarily exist in orgs that cater to non-technical faceless stakeholders. In practice, a big challenge is to avoid being someone who is "not hardcore enough" (i.e. incapable of implementing large scale reusability due to lack of ability, tendency to cave to timeline or other pressures, or distaste for "office politics") but also avoid being "too hardcore" and being constantly in the weeds chasing some cool clever idea that might not align w/ overall picture. One thing that is often overlooked in open source projects with sizable communities is the amount of cat herding you need to do. People have all sorts of ideas for "features and improvements" and 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.

jacurtis 3y ago
> 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.

skeeter2020 3y ago

staff and principal engineerings are still leaders who spend an awful lot of their time coaching and mentoring, they probably just don't have direct people management responsibilities. There are very few situations that will give you an advanced IC title for doing stuff that "no one else can do" because of one word: leverage. It's not economic (in all but the rarest, most specialize cases) for me to say "I want 10x developers who are snowflakes" vs. "I want my senior engineers to increase their sphere of influence and make every developer fractionally better". It's very hard for a senior developer to increase their skills 10% YoY, but actually pretty easy for them to help 20+ developers get 1% better. Staff and Principal developers go deep on the leadership aspects (I shudder to say architecture, but it is the "good" parts of this) and very, very wide on their application & influence. As a result the opportunities for deep engineering work are more like mining than farming. I manage 2 core teams, one a "platform" team made up of all senior => principal engineers, and they spend a lot of their time shepparding other less experienced teams while trying to answer very tough, vague questions like "what bottlenecks do we predict at 10x scale? What can we opportunistically do today?". No one gets huge, dedicated time blocks to code without some degree of accountability and expectation.

PhilipRoman 3y ago

The list you named is a bit strange, I wouldn't put something like docker anywhere near the others, their innovation isn't really on the technical side. If I had to take a guess, a lot of these places are close to hardware. Working with hardware has the additional bonus of often mandating high performance. Any task becomes a lot more exciting when you have microsecond deadlines for controlling an industrial laser.

stagger87 3y ago

I work in an EE dominated industry where staff and principal titles are only handed out to 30+ year veterans who know their domains better than anyone else in the world. These are people who specialized in one thing their entire career (mmWave RF amplifiers for instance). These companies are every where big software is at, and then some. They don't pay great, they are not "cool" to work at. Gov is often the biggest customer. Doing something novel in these fields will require a PhD, a decade of corporate R&D experience, and significant corporate backing.

esafak 3y ago
Everything about this is why people rightly go into software instead.

mathgladiator 3y ago

You're seeing a variant of Price's Law ( https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price https://en.wikipedia.org/wiki/Derek_J._de_Solla_Price) Big tech sucks a lot, and I mean a lot, of the oxygen out the market for these roles. If you take the total population of engineers, then how many engineers are needed to build TCP/IP stacks, new app network protocols (i.e. QUIC), databases, web frameworks? The unfortunate truth is that getting deep experience is rare. Risk aversion is a core culprit; would you trust a tech not supported by a large community? This creates a tremendous market pressure on a handful of players. This is one of the reasons that I had to work at big tech to get the experience and skills that I wanted. For example, when I was at AWS, I read every COE (cause of error) report for the big services. This helped me tremendously both as an IC and leader. Now, I hate that I had to bend the knee to big tech...

simonw 3y ago

> I've been bothered by the fact that most advanced engineering roles like "staff" actually mean "manager who does system design as well" The definition I have generally seen for "staff engineer" is an engineering leadership position without direct reports - I see "manager" as generally meaning "has direct reports". I think this is important: leadership and management are not the same things!

etamponi 3y ago
Can you explain better the difference? I am trying to figure this out myself for a while...
- rokob 3y ago
  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. Engineering management is more on the management of people and engineer leadership is more on the management of products/projects/systems.
  - deprecative 3y ago
    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.
    - joshuamorton 3y ago
      Ehh, I am employed at a company where, despite things being very tense at the moment, I've felt very comfortable expressing to my manager my intent to transfer out of the team I'm currently on and into a different position, as I'm not happy with things as they are. My manager, skip, and director have all been extremely supportive of this throughout the process, despite it taking a somewhat lengthy period of time and putting me (a senior-almost staff eng on the team) in a position where it's very difficult for me to commit to a significant ownership of big strategic things (which is my job) since I might transfer out at any moment. Similarly, a few years back, I expressed intent to transfer away from my team to my manager. He basically said "stick around an extra quarter since you're on the cusp of promotion and it'll be easier this way" (and he was correct, my promotion would have been delayed if I transferred first), and I did and got promoted, and ended up staying longer, for various reasons. Additionally, my managers have all been receptive to my goals in terms of career growth: do I want to lean into management (no!) or into deep technical expertise? Do I want to go for additional promotions, or am I happy to stay in the role I'm in and continue doing the same kind of work? All of this, to me, reads more like career management than job management.

SimonPStevens 3y ago

> Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? They create their own thing from scratch, and turn it into a job. The first 5 from that list were open source creations that became big because they met a need at the time and lots of people adopted them. Which is one route into creating your own thing. I've seen senior engineers who have leveraged lots of domain knowledge to build a prototype of something super useful internally within a company that then grows in adoption and size as people recognise it's value. Projects then start to organically cluster around the core that was built solo.

onion2k 3y ago

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 a special title for people who make amazing things. They're not that different to the rest of us. The main thing they have going for them is an environment that lets them shine - time to research and explore, less pressure to do things that aren't moving them towards the end result we see, and fewer externalities that make them lose focus. I'm not suggesting just anyone could make Linux or Roller Coaster Tycoon, but I am definitely of the opinion that given then right circumstances most people could produce something that other people believe is at that sort of level of complexity. May we all find those jobs one day.

mywittyname 3y ago
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.

groby_b 3y ago

They exist, and they aren't that rare. My org currently has a noticeable percentage of staff+ ICs, not managing, and I'm actively encouraging folks to think careful if they really want management. I am far from the only manager doing that. But yes, jobs are very rare. Staff+ ICs tend to like to stay where they work (because great achievements take time), there's only a limited number of roles, and a lot of this is word-of-mouth in a given field. I'd look either at FAANG - they're large enough to always need staff+ folk - or startups once they have round A. They live or die by having really experienced and productive staff+ folks, and they're large enough that they can offer staff+ interesting challenges. Why not pre-founding? At that point, any good staff engineer I know is driven enough that they'd be better off just starting their own. In a small startup, the founder is either technical and interested in solving the hard questions, or non-technical and you'll have essentially a CTO role, but without founder credit. It's not a hard-and-fast rule, there are exceptions to everything - but that's where I'd focus my search if I were to search for that kind of role.

brianm 3y ago

Most companies, in my experience, don't actually know how to make use of Staff+ engineers. I spent years at a medium sized public "tech" company just trying to help the company change engineering enough to make use of these folks, and we go to a place where we could... mostly. FANG and FANG-model (anyone copying FANG engineering/product model) companies do it well and have the bulk of success cases. Look for engineering-lead companies first, product lead companies second. A key question when interviewing is "how is the roadmap established?" You want answers where senior leadership establishes goals (strategic or metric), product provides their understanding of opportunities, and engineering decides what to actually do. Even then, there will be the common failure model of EMs doing the roadmapping, not senior (staff+) ICs, but you can tease apart how that works, as it is always going to be a mix.

feoren 3y ago
> Most companies, in my experience, don't actually know how to make use of Staff+ engineers. Absolutely spot on. Making use of Staff+ engineers requires giving them a hard problem that would catapult your company forward if it were solved, and a ton of autonomy in how they go about it. Give them dedicated time to prepare presentations on what they're doing and what they've learned recently. Give them dedicated time to mentor other staff members. Give them a routine, but not a schedule. Stop asking them for so many fucking estimates. Give them access to support staff. And then get your fucking hands off them and let them veritably radiate value to your company. All of this is, of course, antithetical to whichever imposter-syndrome micro-managing MBA vice president happens to have landed in the chair that gives them authority over these people in their never-ending game of Management Musical Chairs. No fucking way are they going to let some grunt just work on a hard problem without constantly getting in their way, nagging them about pointless deadlines and bullshit estimates, and showing visual progress via good-looking DOM elements so they can take credit for it and get Business Points before their 2-year tenure in that chair is up and they move to Head of Brand Awareness or wherever. No: doing so would reveal that their entire position is literally pointless. Can't have that.

lifeisstillgood 3y ago

This is the hidden side of staff engineer. The bit books don't get written about for the same reason "how I got rich" books leave out the people who worked hard but got less. Somewhere someone has to have the time to build out the tools, then dig the foundations and lay the scaffolding and the supporting walls. None of which looks like the artists impression and none of which has a web interface you can show. So Staff engineer is like architect. Holding the nervous customers hand while they spend a fortune to have a large hole in the ground. You cannot build a bridge by stacking bricks in front of the customers feet one at a time in a nice iterative process. You cannot always "see" progress at the user level. to me the signature of really good software is when one marginal change delivers outstanding value and the engineers just say "was that it".

NBJack 3y ago

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.

feoren 3y ago
> 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." I would define that as "software engineering". What else are any of us doing all day? The compiler's job?
- jmchuster 3y ago
  It's the scale of it. "Here is a vaguely understood problem, that might take 2 hours to solve." "Here is a vaguely understood problem, that might take 2 years to solve." Though if you're used to the latter timescale, you might not consider the former as all that "vaguely" understood.

guhcampos 3y ago

My single tip is: look for Product companies, not Service/Project companies. This means looking for companies who build and maintain a product, SaaS or not, which they offer to customers, and avoid all sorts of consulting, offshoring, nearshoring, whatevershoring third-parties. Project/Service companies draw little value from engineer familiarity with the systems they work on. Contracts and projects come and go, and everyone needs to learn new systems, processes, and technologies all the time. Experienced people end up as Project managers because that's the only path to career growth. Product companies, on the other hand, suffer a lot from engineering turn-over, since they have this one complex system they need to babysit forever, and ever time someone leaves, the accumulated knowledge built on that person leaves with them (likely to a competitor who really benefits from that knowledge as well).

feoren 3y ago
As someone who has worked at a "Project/Service" company for way too long, I wholeheartedly agree. It's a horrible way to build software and will drain your soul. Good software is both much more expensive and much more valuable than most people realize, and one contract or client is never enough to give it the attention it deserves. Your clients will wonder why your $200k custom software doesn't work like Excel / PowerBI / some other product with tens or hundreds of millions of dollars of investment. It will wear on you that you simply can't give your software the love it deserves solely on the tab of one single client.

coev 3y ago

Doug Crockford was "Distinguished Fellow Engineer" or some title like that at Paypal.

kimixa 3y ago

The only time I've seen anyone really do half of what this books describes as a "Staff Engineer" was at a small(ish) hardware company, PowerVR, where the OpenGLES driver team was 5-6 people, the team lead was a developer and architect who also did a bit of management, rather than the other way round. Then there was a manager on top of them in turn for multiple teams, but they weren't involved in the technicals at all, not even in the loosest "architecture design" ways, they purely did the people management. In a larger company now, still working on GPU drivers (AMD, but not the "main" platform), there's a couple of people who might do a bit of this, but feels more like you get specific domain experts rather than anyone designated by the company. The team is notably larger than at PowerVR, and there is a "Manager" who is more involved in doing things like placating customers and prioritizing work and issues, but again completely uninvolved in the actual development. In none of these examples does the job title have any relation to the differences in their work, both used completely different stacks of terms and difficult to compare cross-company. But I guess it's all "Hardcore Engineering", and even the newest members of the team are expected to design systems themselves. Hell, straight out of university at PowerVR I was designing and implementing my own stuff, and significant systems not just following an already concrete architecture. But it was a small enough team everyone was involved in feedback, and I did feedback to them in turn. So I guess GPU drivers are still greaybeard "Hardcore Engineering"? This may be helped by driver development often being pretty well defined, you have a spec (which you may have been involved with designing, but very much a large collaboration), you have hardware architects and another team trying to figure out the next generation might look (are they the "true" architects here?).

coliveira 3y ago

> Where do all the hardcore engineering jobs live There is NO such thing as hardcore engineer job position that doesn't involve a lot of management. All the good engineers that get jobs are the ones who do management work as well as coding. If you cannot do this, the industry will just close its doors for you.

trgn 3y ago
> There is NO such thing as hardcore engineer job position that doesn't involve a lot of management So bizar. I've been in a few companies with senior "hardcore" engineers heads down in code, without management responsibilities. > If you cannot do this, the industry will just close its doors for you. Wait what? A good engineering company will strive for a mix of seniority within teams of ICs. Some of these seniors may become "staff", which usually means, can talk tech stuff to the brass.
- coliveira 3y ago
  It only changes the kind of management responsibilities you're talking about. Yes, some positions will have zero employee management, however you'll be responsible for product management. There is no product in a big company that can be created with zero collaboration, so you'll be responsible for managing collaboration with other groups, determining features and getting ok from management, making sure that others are doing their work, etc. It is management nonetheless, sometimes with lots of meetings, just with a different goal.
- throwway120385 3y ago
  Most companies are not "good" engineering companies. They are at best mediocre.
proc0 3y ago
In my opinion this is a big reason software is so brittle, needs to be constantly patched and updated, and overall innovation in software moves very slowly. Having engineers do management work is undermining how hard engineering is -OR- underestimating how powerful software is. In other words, the Idea is that engineers adds more value to a company if they also do all these management tasks, which implies that engineering is not enough and is not as valuable on its own - something I would contend because as we can see software is capable of amazing things like AI that will soon automate all these management tasks anyway. If companies invested in their engineers doing only engineering, then people could maximize their skills, and reach those new levels of productivity thanks to advanced software. Instead the industry limits engineers, and insists on them hitting a technical ceiling, effectively pushing them in a non-technical direction in favor of hiring younger engineers to do the "grunt work". Software engineering is only grunt work when you don't understand its true potential, and its endless complexity that takes a lifetime to master.

bippihippi1 3y ago

smaller companies, and new teams in larger orgs. if you work on an existing system there's less 'interesting' work and more iterative improvement. larger orgs can produce hardcore stuff, it's just usually too large to attribute all of the 'interesting' stuff to one person. a microservice is just a library with infrastructure, not that much different from writing a small part of a 'hardcore' project. also you can start your own project and do something amazing

personjerry 3y ago

At big companies there are high level IC roles, supposedly "mirroring" the manager levels, for people who are the "creators" and effect change in tech on a large scale without people management. For example I remember at Facebook I attended a "class" on keyboard shortcuts, taught by one of the creators of a *nix utility (I forget which)

VirusNewbie 3y ago

I've worked at a big telco and now FAANG and I can tell you there is so much non CRUD work it's crazy. There are very very hard technical problems to solve in FAANG.

leothecool 3y ago

We're all out here chilling in the midwest working at lifestyle businesses.

alistairSH 3y ago

Depending on the company, this could also be a senior architect, technical fellow, or something similar. Or just an engineering manager or tech lead. It's hard to know from the outside exactly what each role really means. My employer has Technical Fellow at the top of the architect job family. It's equivalent to a director or senior director in seniority, but remains an individual contributor. These are the people creating (or more accurately, enabling the creation of) the really amazing software here. But, given the business we're in, the software they build is never going to enter the common lexicon like Uber or Google or whatever. And I'm a little confused by your "most companies are consumers" comment. Sure, in a literal sense, most software projects are built using tools written by somebody else. If you want to be building those tools, you need to get a job at someplace that builds tools (which usually means proving yourself an expert in a particular niche/tool/whatever). But, there's plenty of software between "simple CRUD" and "creators the next [impactful tool or infrastructure]"

agentultra 3y ago

You could read the main linux kernel git log and see who the top contributors are. If you prefer system level programming there are jobs out there and plenty of work to do. I dunno if this counts as, "hardcore engineering." To me, engineering, involves many other skills other than writing code: being able to specify systems clearly and, as the occasion demands, formally is a part of engineering; communicating with others; Knowing which trade offs to make depending on a situation, etc.

rmk 3y ago

There aren't too many hardcore engineering jobs. They are being done in startups where hard problems are being solved, and even there the average startup is just a website which is acting as a broker in a two-sided marketplace, or some variant thereof. If you step back and think about it, it makes sense. The majority of companies are one-trick ponies, maybe following up with a few additional products. Incremental development is the path of least risk once product-to-market fit in a large market with high growth is achieved. As public companies (and late-stage startups or private companies) are incentivized to reduce risk, the majority of the people will be doing incremental work. The growth of the pseudo-technical managerial class in the form of Product Managers, Project Managers, and umpteen levels of mid-level managers further encourages the relative lack of 'hardcore engineering'.

jameshart 3y ago
Why do so many people in the tech industry have so little respect for their peers who work elsewhere in the industry? The idea that large companies aren't solving hard problems, that that's only being done at startups, and that large companies are 'one trick ponies' is just incredibly myopic. Have you worked at a large publicly traded tech company? Sure, in any business a bunch of the systems will be trivial. In larger businesses - especially ones that have grown through acquisition - there's also some scaling-law complexity that means they have to also do a bunch of annoyingly trivial work gluing together lots of duplicative and redundant trivial systems. When you look in from the outside of a large business that mess can definitely obscure the fact that at the heart that stuff is all in support of, usually, several significant and impressive engineering achievements, which support and drive that business forward. And they're probably performing operations that, from the outside, you would hear the name of and think 'well, that doesn't sound very difficult'. I'm going to give a non-software example, that I think might show a little bit of an analogy for how 'engineering' at big companies can be at the same time operating at a complexity you wouldn't imagine, and yet be accomplishing something you might think from the outside is totally trivial. Jump to this timestamp in the recent Smarter Everyday video about Kodak's film manufacturing line: https://youtu.be/mrJP82ZZiag?t=1742 https://youtu.be/mrJP82ZZiag?t=1742 See that workshop? Those precision engineered toolheads they call 'hearts' are the punch+die sets that they use to cut sprocket-holes in film. Everything there is bespoke, custom-made, and meets constraints you would never have thought of. It's engineered. Software engineering in large companies is like that. If you don't think that banks contain software systems as complex and carefully engineered as those hearts? Or that manufacturing control software isn't in the same league? Or that the inventory management systems that drive a large retail business aren't on that level? You just have no idea what engineering is.

zerr 3y ago

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.

opportune 3y ago

I know people like this, I work on major public cloud products. Sometimes they are “staff” or other high level-titled. But you have to recognize some of the projects you’ve listed are mostly notable because they are very well documented and have a lot of OSS (besides RTC) mindshare; there are just as technically challenging and valuable projects that are less well known because they are proprietary sold software.

greenthrow 3y ago

Have you read the book in question? The whole point of it is that it is not a manager position.

MobiusHorizons 3y ago

What you are talking about are engineering investments. Generally you have to make the case for those. Management will generally not want to make those, because they are costly, and require long term maintenance. You have to prove that it will be good for business somehow. No one gives this to you, you fight for it, or build it without asking

trelane 3y ago

> Where are the docker/redis/next.js/linux kernel/qt/roller-coaster tycoon creators? Unless they're very fortunate, they're wishing they could do the groundbreaking stuff that's in their bones, whilst they get ordered to ignore it, to other stuff that's higher immediate priority. So they do the needful while tinkering as they can find time to. > Where are the people creating amazing software and do they get a special "advanced developer" title? No, they get no special title. They just get ignored, unless they get lucky and find a manager that supports them.

YesBox 3y ago

>Where are the roller-coaster tycoon creators? Hello! I'm making a roller-coaster tycoon inspired game, in the form of a city builder. I ended up creating my own path finding algorithm that 10x's the performance of A*. I felt this would be useful since pathfinding is one of the major slowdowns of simulation games. https://twitter.com/YesboxStudios/status/1647224184597102592 https://twitter.com/YesboxStudios/status/1647224184597102592

closeparen 3y ago

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 set up to socialize it out of younger engineers and to have an immune system to reject any more senior engineers who endorse it.

inimino 3y ago
And the stronger this rejection, the stronger the pressure on anyone who represents a counterexample to the dogma to leave.
- closeparen 3y ago
  Strong coders are usually pressed into technical leadership roles where they don’t have much time to code. It’s true that if you shirk your non-coding duties you’ll get managed out.

pkaler 3y ago

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!)

tourgen 3y ago

[dead]

quickthrower2 3y ago

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.

urthor 3y ago

Research. End of the day, everyone at Bell Labs was a researcher with a PhD. Engineering, bringing research to people, trends to CRUD over time.

jldugger 3y ago

> 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 traveling between big tech companies but mostly as a prestige recruiting / consulting role. Or Torvalds, whose finances I don't really understand -- multiple sources say he gets a million dollar salary from the linux foundation? You might also argue that the people who put more value on their skills as "hardcore engineer" end up in small firms and startups where equity comp can end up paying them what they're worth if the skills pan out. There was a "why is Google behind openAI even though they published the transformers paper" post recently that hinted that all the authors have left google for greener pastures, which supports this thesis. [1] https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e88a8 https://gist.github.com/antirez/6ca04dd191bdb82aad9fb241013e...

jameshart 3y ago
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).

ww520 3y ago

At staff and principle level, the job becomes mentoring and working with other senior people under you. There might be a business need/problem, and you have the vision to address it. You gather the requirements, do feasibility studies, evaluate the technologies, nail down the architecture, design the components, and work closely with other senior engineers on the prototype/design/implementation. You might code up the prototype and proof of concept during the exploratory phase. You might code up couple components you believe you're the expert in doing it. At the end of the day, you're the voice and the advocate to ensure your end-to-end vision is implemented.

facet1ous 3y ago

There are a few "hardcore" staff/prinicpal engineers at my company (a well known tech unicorn). They are basically OGs who were a big part of the company's early success. Really smart and saavy guys who are left alone to focus on executing on big stuff. The reality for other staff engineers here is exactly opposite though - you're not allowed to just be "executing" and your day consists of being stuck in meetings, doc writing, and management-lite. Honestly it's so bureaucratic and so far removed from the actual tech I really got turned off from that career path as I got more visibility into it. For smaller companies it's probably much more fulfilling though.

SergeAx 3y ago

The exact idea of the Stuff Engineer is that they are not managers. They are leaders though, it is a different matter.