[HN Gopher] The Staff Engineer's Path - Book Review
___________________________________________________________________
The Staff Engineer's Path - Book Review
Author : _sJiff
Score : 274 points
Date : 2023-05-17 13:18 UTC (9 hours ago)
(HTM) web link (smyachenkov.com)
(TXT) w3m dump (smyachenkov.com)
| danwee wrote:
| I certainly like that companies are introducing yet another step
| in the IC ladder. Before it was like: junior1 -> junior2 ->
| senior1 -> senior2 -> manager. And the money you get by being
| junior2/junior2/senior1 is not that much. Nowadays I see
| companies doing: ... -> senior1 -> senior2 -> staff1 -> staff2 ->
| manager. So, in the past I have quit a job at level staff1
| (decent money), just to go to another company where they label me
| as senior 2 (more money, but this is not the topic of discussion
| here). So now, I have yet another opportunity to make more money
| by being promoted to staff1 (and then staff2) basically doing the
| same thing I have been doing all these recent years.
| swozey wrote:
| I'm staff and I don't consider Manager a vertical step at all.
| It's a horizontal. Completely different type of job and I
| really doubt they make much more if more at all money than me.
| I would never go manager.
| throwaway1777 wrote:
| At meta and google they certainly don't make more, the L6
| manager and engineer bands are the same. Same for l7. At
| director level the bands are so wide it may not be the same
| between ic and managers even if it is in theory.
| JaumeGreen wrote:
| I'm a manager now and it was a lateral move from development,
| no salary increase. So yeah, sometimes managers earn around
| the same as the top people they manage.
|
| Heck, I wouldn't mind earning less than some of the most
| brilliant ones. In fact I think I do earn less than someone
| that reports to me.
| pc86 wrote:
| I would stay away from any company that treats Staff as a
| natural progression on the road the management. You just have 4
| senior levels at that point, which is fine if that's what you
| need/want, but it shows a genuine misunderstanding of the IC
| path.
|
| I'm a big fan of the 1 and 2 levels for mid+ as it gives a
| little more granularity, and the opportunity to increase pay a
| bit more and still have reasonable pay bands. But at the last
| senior level you really need to start focusing on whether you
| want to be in the IC track or the management track. You can
| certainly switch (I have) but they're very different and "ok
| you performed well as a Staff 2, we'll promote you to EM1 now"
| is a red flag in my opinion.
| broguinn wrote:
| Read this; helped me get to staff. Some takeaways:
|
| - If your management chain isn't supporting you into a staff
| promo, it's because they don't value the work you're currently
| doing.
|
| - A staff engineer isn't a highly-productive senior engineer.
| Stop optimizing for the things that got you promoted to senior.
| ergocoder wrote:
| This cult of staff engineers really need to go away.
|
| People read it and all of them like to act like a staff engineer
| when in fact there are only available slots for a fraction of the
| engineers.
|
| Now nobody wants to fix bugs and improve product quality. Why?
| Because those tasks are not staff-level work.
|
| The reward system and the definition doesn't work.
| digging wrote:
| Alternatively, I've worked with Staff Engineers who are still
| fixing bugs, and also building (maybe staff-level?) tooling and
| project improvements. The most significant issue is the lack of
| standardization of expectations. "Staff" doesn't mean anything
| in a vacuum because it doesn't mean the same thing between any
| two companies.
|
| Personally, I love doing senior stuff. I don't know if I even
| want to be staff at any point, maybe I'll want a different
| challenge someday, but I still get a lot of enjoyment out of
| churning out high-quality code and shaping things at multiple
| levels. But if I stay where I am, I'll eventually be promoted
| to staff with minor shifts in the work I do.
| [deleted]
| zmj wrote:
| Those can be some of the most fun problems. Fixing deeply
| rooted reliability or scalability problems in the business's
| core product without disrupting users? That's absolutely a path
| to recognition and rewards.
| why5s wrote:
| From personal experience: no it is not. This mentality leads
| to nothing but frustration and burnout as upper management
| sends you to tackle your "staff"-project.
|
| Titles are all based on organizational politics and the
| macroeconomics at the moment. Were you hired during the
| 2021-2022 hiring spree where companies would give anything to
| keep engineers from getting poached? You probably were hired
| at Staff. If not, then what were you doing? Lol these folks
| were the first ones laid off.
|
| Personally, I received my highest raises in 2021 and 2022.
| Multiple salary (and equity) bumps; a title bump. Life was
| fucking good.
|
| Nowadays, you can just be glad not to get laid off. Instead
| of the promotion they promised, you get a slap in the face
| and some chump change.
|
| I know I sound jaded but the fact that there are MULTIPLE
| books on "Staff"-level engineering (all un-ironically written
| by managers and executives rather than ICs) is completely
| laughable.
|
| /rant
| 29athrowaway wrote:
| Many staff engineers are simply people good at hiding their
| weaknesses and have no more expertise than an average senior
| engineer. Same as many architects.
| amccloud wrote:
| So pretend to work?
| 0xbadcafebee wrote:
| I can't wait for this cult-of-the-staff-engineer hype-cycle to
| die. We need better managers, not the new rockstar 10x IC.
| charcircuit wrote:
| Staff engineers aren't "rockstar 10x IC."
| 0xbadcafebee wrote:
| It's certainly how they market themselves. Look how great we
| are, we're leaders, we're mentors, we're leaders, we think
| bigger, we make a bigger impact, blah blah blah.
|
| And it's a crock of shit. It's not up to an IC to decide
| strategy, make executive decisions, or lead a team, unless
| Lead or Manager is in their title. Thinking big,
| prioritizing, choosing what to work on, etc, is something
| every engineer should learn to do, as part of a team. And
| that team should be led or driven by an individual whose job
| it is to, hierarchically, be in charge/responsible, and all
| that entails.
|
| At the highest possible level, a staff engineer can be the
| "idea person" who looks at everything and can make proposals
| or lay some groundwork. But the "glue" of connecting a team
| to the rest of the organization needs to come from management
| and leadership, because they're the ones who can reach out to
| everyone without overstepping, and take the flack when it
| comes.
|
| Here's another example: https://staffeng.com/guides/staff-
| archetypes/ This dude is claiming that these four separate
| roles and skillsets are just types of Staff Engineer. This is
| such ridiculous bullshit I don't think this person has
| actually done time in large engineering orgs. The tech lead
| doesn't even have to be very good, they just need to herd
| cats and be a tie breaker. The architect is _an architect_ ,
| a speciality distinct from the rest of software/systems
| engineering that doesn't even require coding. A "solver" is
| known in other circles as a "fixer", which is another word
| for someone who doesn't take shit and gets a job done, which
| doesn't require much other than willpower and attention. And
| a "right hand" literally is just shitty
| organization/management taking advantage of someone who gets
| things done yet has no political power.
|
| In any case, all these resources talking about Staff
| Engineering are bullshit hype-cycle for a very simple reason:
| if you're a Staff Engineer, you know all this shit already.
| If you're not one, reading these books won't make you one.
| It's like thinking you can become a great woodworker by
| reading a book on woodworking. It's all just career
| voyeurism, or aspiration porn, written up to sound
| authoritative, but is actually completely made up, because
| it's actually just normal work that somebody wanted to sound
| more important.
| faitswulff wrote:
| Can anyone compare this book to Staff Engineer: Leadership beyond
| the management track by Will Larson?
| msoad wrote:
| I'm a Staff Engineer, but I hardly do anything that this book
| describes. Maybe it's my company, but we have so many Staff
| Engineers that if we all were to do this stuff, nobody would have
| time to do the actual work and there would be too many people
| trying to lead.
|
| Perhaps the levels are diluted and my title doesn't match my
| actual role at my company, but it feels like this is an industry-
| wide phenomenon.
| JackMorgan wrote:
| Titles are very much diluted.
|
| I've seen companies hire college sophomores who have never
| heard of the concept of a database and make them Sr Engineers
| on a analytics teams. I've seen Sr Engineers hired with one
| year of relevant experience.
|
| At this point, "Sr Engineer" is just the new "Jr Engineer".
| There's nothing wrong with this, but indeed, Staff Engineer
| tends to mean 8+ years of experience.
| 0xbadcafebee wrote:
| It's because we still have no standards as a profession.
| Whatever bullshit trends in silicon valley, suddenly everyone
| follows it, petrified that they might get left behind or are
| missing some important new thing.
|
| I remember when Systems Administrator was a noble and
| important profession full of smart, talented people. But a
| lot of people misunderstood it and made fun of it, so it
| became an unattractive title, and instead of changing the
| role, they just made up new titles. Now they're cool and in-
| demand, and still nobody understands what they do.
| yieldcrv wrote:
| Thats because nobody can get hired as an entry level or
| junior engineer
|
| If you arent internalizing the senior title immediately then
| you will get nowhere
|
| If you're not forming an LLC and putting yourself as an
| junior employee of that shell company with some verifiable
| information or project, then I dont know how to help you
| strikelaserclaw wrote:
| Staff engineer is the new senior engineer.
| basisword wrote:
| Can confirm. Didn't want to be staff and don't think I'm at
| that level, but it was the only way they could give me the
| raise I was demanding within the rules of the silly HR system
| they'd built.
| ravenstine wrote:
| That's been my suspicion for a while now.
|
| The last 3 companies I've worked for had no juniors and mid-
| levels, but only seniors and a handful or staff engineers.
| What staff engineers did on a day-to-day basis was hardly
| different from what the senior engineers do, besides having
| more responsibilities and maybe more say over things like
| architecture. Depending on the company, a staff engineer
| could be managing or not managing at all. In general, I don't
| think these title really mean a whole lot, that is unless one
| is intent on managing specifically.
| awill88 wrote:
| I disagree but only because I thought this way and it hurt my
| performance.
| gautamdivgi wrote:
| Yes, but if you stay where you are and don't push the
| managers you work with to take execution responsibility you
| will damage your career.
| shimst3r wrote:
| Unpopular opinion: With quickly growing organizations and
| therefore more inexperienced people managers, promoting
| someone to staff engineer is an easy way out of
| responsibility.
|
| How often have I heard "you're at a point in your career now
| where a people manager will only hinder you" to justify not
| being capable of supporting me.
| pc86 wrote:
| Curious your thoughts on who a Staff should report to. I've
| been at a handful of places where there were Staff
| Engineers (some of them even deserved it!) and it always
| seemed like the promotion from Senior to Staff came with a
| change in reporting structure, where now instead of
| reporting to a Manager you're reporting to a Director or a
| VP, even the CTO in smaller orgs.
|
| I think this is a good indication of increased
| authority/responsibility, but also an easy way to shirk
| management responsibilities as you said. How much 1:1
| management is a VP or CTO going to be doing with a Staff
| Engineer? Do you really want a VP with all the political
| nonsense that comes with that type of position to have
| their own pet engineer they can bother about things?
| mkozlows wrote:
| I'd argue that if you're a staff engineer, you need to be
| adept at navigating the "political nonsense." A
| director/VP should be able to think of you as at least as
| senior and capable of handling ambiguity and being self-
| directed as any manager.
| Swizec wrote:
| As a staff in practice, but not in title, here's how it
| works for me: My manager and I are at the same level. We
| work as peers. They handle the people stuff of the team,
| I handle the technical stuff of the team. They help with
| routing people/HR/management questions, I help with
| routing technical questions.
|
| If you think _" Gosh, that person (on another team) sure
| was rude"_, that's a question for my manager.
|
| If you think _" Gosh, I sure have no idea why that API
| (from another team) sucks"_, that's a question for me.
|
| In terms of reporting to my manager it feels more like
| having a corner-man in the boxing ring than a boss. I
| fight the fight, they say _" Hey you're dropping that
| right hand on your left hook, stop that or you'll get
| rekt. Here's some ice"_. And they spend more time
| thinking about and navigating politics-like issues in the
| org than I do, which means I can lean on their expertise
| when "org stuff" is needed.
|
| I probably have similar or more years of experience than
| my current EM. The person we both report to, happens to
| be a true greybeard.
| msoad wrote:
| You're describing being a Senior Engineer. Staff
| (according to this book) goes beyond that.
| pc86 wrote:
| This tracks with what I've read in your newsletter :)
| semiquaver wrote:
| Staff engineers that report to directors or whatever the
| equivalent 2nd or third mgmt level is are most effective
| in my experience.
|
| An important part of the job is to "borrow" your boss's
| authority and for that to work they need to have some.
| I've seen staff engineers be ineffective because of their
| boss's position many times.
|
| Reporting to someone higher than director you start
| getting too disconnected from on the ground stuff
| (architecture astronaut syndrome) and lower the ground is
| all you can see.
| sarchertech wrote:
| I've seen the opposite problem far more often. Less
| experienced managers who are perfectly fine at managing
| junior engineers attempting to manage senior engineers in
| the same way.
|
| It's refreshing when a company realizes that staff
| engineers with 15+ years of experience don't need daily
| management.
| awill88 wrote:
| It might depend on the organization of course but I hear what
| you mean here. It does seem somewhat of a phenomenon..
| pc86 wrote:
| I've always viewed the levels sort of like this, obviously very
| dependent on company:
|
| Juniors need hand-holding at every step. They may be new grads
| who don't even know how to behave in a professional environment
| or very inexperienced folks 1-2 years out of school taking a
| role in a completely different language they're unfamiliar
| with. You're talking to them anywhere from 5+ times a day to
| every other day as they transition up. They may have lots of
| meetings, especially during onboarding, but they're mostly
| listening. Their day-to-day is almost entirely "how" with very
| little "why."
|
| Mids need hand-holding for the bigger picture stuff. You still
| need to give a general shape to their work but you can expect
| them to look up the docs for your validation library if they
| don't know how to do something, and you can expect to format
| and structure their code and PRs the right way every time (the
| junior will likely ping you on Slack asking how to write a
| custom validation function at least once). But it's unlikely
| you're going to need to talk to them daily. Hopefully they have
| large blocks of uninterrupted time to work as these are the
| folks churning out lots of tickets. They can also start
| thinking more about "why" than "how."
|
| Seniors shouldn't really need hand holding for much of
| anything. Give them a feature or an entire product and they
| should be able to figure out approximately how to do it and
| what resources it will take. More meetings than mids but still
| need uninterrupted time. IME my productivity starts to really
| dip if I don't have at least two half-day blocks in a week. I'm
| in a new-ish job (first year still but 14 years in industry) so
| have been lucky so far but have been starting to block off
| chunks if I see my schedule filling. Seniors are probably
| running several of the meetings they're in, and maybe directing
| work for juniors and mids. I've been in companies where the
| line between Senior and Engineering Manager is very blurry as
| well with new EMs still spending 1/4-1/2 their time writing and
| reviewing code. And in most companies this is the "terminal" or
| "professional" level where you're not expected to move beyond
| here. Lots of folks will hit senior and be there for 15, 20, 25
| years until they retire.
|
| Staff is where the amount of code you write starts to drop off,
| meetings start to ramp up (you're no longer able to block off
| half your day), and in my opinion the biggest difference, you
| don't get _assigned_ anything to work on. You 're expected to
| have intimate knowledge of your business domain, your technical
| domain, and the challenges in both, and formulate plans to use
| technology to ease problems in both. I also feel like this is
| the first level where most companies don't need them, including
| a lot that have them. We have about 85 software engineers where
| I am, and two of them are Staff, which seems like about the
| right amount percentage-wise. There's only so much _big_ work
| to go around and while there might be a lot of people capable
| of doing it, you don 't want 10% of your engineers to be Staff
| and fight over the 0.5-1% of Staff work that's available. This
| is also the level I see it much more important what you're
| doing outside of work. Not as far as side projects, but going
| to conferences, speaking, user groups, having content available
| that works as advertising for your and your company, etc.
|
| And then of course Principal where 99% of companies don't have
| or need them, where you're basically a VP or Director but on
| the Individual Contributor track rather than management. These
| are going to be so company-specific it's not even worth talking
| about them except in the context of a particular company.
| You're probably at Google or Microsoft or similar at this
| point.
| dogline wrote:
| I think there's another past staff/senior where you get to
| tell all of the other groups to leave you alone, and you're
| back to being dirty and building cool things. This is where
| you're most valuable and where they want you. But, you need
| the confidence that you've got it handled and you're trusted
| to communicate as needed.
| pc86 wrote:
| Yes this is the Guido/Rasmus level we should all aspire to!
| nvarsj wrote:
| Everyone in this comment thread seems to have a different
| definition of staff engineer. And that is kind of the problem
| with this term. It's almost devoid of any meaning now, like the
| ubiquitous VP title at a bank.
|
| This book should probably be titled "Being a staff engineer at
| big tech - how to navigate the performance process to get
| promoted as an IC". From my brief skim, that seems to be what
| it's about.
| itissid wrote:
| One resource I always wanted to have was how does one figure out
| the responsibilities for a new role that one is interviewing for
| and is advertised as mid level:
|
| 1. Writing, reading, reviewing software most of the time.
|
| 2. Some amount of planning on medium sized projects(2 engineers)
| you are handed over. You can thus iterate on new small(ish)
| features pretty easily.
|
| Like assuming a team of ~5 engineers, how does one go about
| quizzing the interviewer about different aspects of the role
| based on prior experience?
| Crash0v3rid3 wrote:
| Any related books for Senior Staff and Principal engineers?
| fizwhiz wrote:
| These roles likely comprise less than 5% of all engineers at
| big tech companies so I would be pretty surprised if such a
| book exists.
| jjice wrote:
| I'm in the middle of listening to this book and they talk about
| "Staff+" roles some inside of it. The books describes the
| blurry lines in there, but it does talk about that next level
| in general.
| [deleted]
| [deleted]
| Tehnix wrote:
| This is honestly a great resource! Funnily enough I've been using
| it internally at my company to both:
|
| - Facilitate conversations and a workshop with other Managers
| around what our expectations generally should be for Staff+
| Engineer levels
|
| - Drive a deeper conversation with each of the Engineers I'm
| responsible for, to help them explore more of the "untold" parts
| of the IC role, what that could look like, and how they could
| work towards it
|
| Freeform diving into it with people has been quite beneficial for
| many that don't have much of a clear idea of what it means to go
| beyond senior, and how to navigate the ambiguity that it can
| bring with it.
|
| I've found that each person took away their own specific things
| from the book which was quite fun to see :)
| Xeoncross wrote:
| 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.
| agentultra wrote:
| 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.
| trelane wrote:
| > 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.
| eatonphil wrote:
| 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 wrote:
| Out of curiosity, do they have junior engineers too? I would
| love to work on docker or jetbrains for example.
| jacurtis wrote:
| 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.
| eatonphil wrote:
| 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.
| Meszek wrote:
| 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?
| jacurtis wrote:
| 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.
| reasonabl_human wrote:
| '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.
| eatonphil wrote:
| 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.
| esafak wrote:
| 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.
| sukki07 wrote:
| 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
| tourgen wrote:
| [dead]
| stagger87 wrote:
| 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 wrote:
| Everything about this is why people rightly go into software
| instead.
| mathgladiator wrote:
| You're seeing a variant of Price's Law (
| 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...
| HEmanZ wrote:
| 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.
| rubiquity wrote:
| 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.
| rmk wrote:
| 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'.
| guhcampos wrote:
| 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 wrote:
| 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.
| PartiallyTyped wrote:
| 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.
| simonw wrote:
| > 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 wrote:
| Can you explain better the difference? I am trying to figure
| this out myself for a while...
| alistairSH wrote:
| I'm a software engineering manager.
|
| I'm responsible for the wellbeing of my direct reports. I
| need to ensure they can grow their careers. I need to know
| when they're stressed or burnt out or bored. I need to
| manage projects and be a shit umbrella.
|
| While I am technically strong, I have architects and
| technical fellows who are WAY stronger than me. I work
| closely with them to ensure we're adopting the latest best
| practices and tools. They do much of the system design.
| They also mentor newer employees, but they don't have
| direct responsibility for those employee's careers. And
| they don't have direct responsibility for the success or
| failure of any given project.
| H8crilA wrote:
| A Staff Engineer doesn't really have to care about for
| example people that have a rough patch, or about notorious
| assholes ruining the team's morale. That's mostly a
| people's manager problem.
|
| On the other hand people's sense of who they should really
| listen to always skews to their manager (the person that
| can fire and/or promote them, or at least has the most say
| in the process).
| rokob wrote:
| 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.
| ska wrote:
| In this context (and the usage is not always consistent)
| it's probably easiest to think about leadership as an
| activity and (people) management as a role. If you are not
| formally responsible for some aspect of other peoples jobs
| and career you are not "managing them" but you may be
| leading them (e.g. as a senior engineer, or mentor, or in
| terms of a project design, etc.).
| varjag wrote:
| Leadership: you can tell them what to do.
|
| Management: you can change their pay grade.
| hgsgm wrote:
| Manager gets evaluate by the performance of their reports.
|
| Engineer gets evaluated by the products they contribute to
| that launch.
| simonw wrote:
| To my mind, management is about having direct reports and
| doing a lot of work around things relating to that
| responsibility: quarterly reviews, compensation and
| promotion discussions, assigning work and suchlike.
|
| Leadership is about leading: helping the company make
| strategic decisions about what problems to solve and how to
| solve them, mentoring and inspiring and educating others,
| generally up-leveling the wider organization but without
| the direct responsibility of managing individuals.
| pc86 wrote:
| > _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 wrote:
| 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 wrote:
| 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 wrote:
| > _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.
| bippihippi1 wrote:
| 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
| PhilipRoman wrote:
| 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.
| markus_zhang wrote:
| 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.
| kimixa wrote:
| 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?).
| losteric wrote:
| 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 wrote:
| 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 wrote:
| 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
| MobiusHorizons wrote:
| 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
| leothecool wrote:
| We're all out here chilling in the midwest working at lifestyle
| businesses.
| quickthrower2 wrote:
| 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.
| UncleMeat wrote:
| 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 wrote:
| 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.
| throw_away1525 wrote:
| I used to be an engineer in a traditional engineering field
| in heavy industry, now my job title is "Software Engineer".
| I still consider myself an engineer, and what I do with my
| team to be engineering.
|
| Creating amazing things yourself that others struggle to
| replicate or contribute to is more in the realm of
| craftsmanship, in my opinion, and not engineering.
|
| I can appreciate both good engineering and good
| craftsmanship. And I also often find myself doing (and
| enjoying) what I would consider crafting and not
| engineering - the lines can be blurry and as programmers we
| often end up doing both (sometimes at the same time!).
| Nothing wrong with it. But it is something that is distinct
| from engineering, in my opinion.
| ughitsaaron wrote:
| I'm assuming Rust here refers to the game and not the
| programming language?
| Xeoncross wrote:
| Graydon Hoare created Rust as a personal project while
| working at Mozilla Research in 2006 -
| https://en.wikipedia.org/wiki/Rust_(programming_language)
|
| Not many devs create the core of what is arguably the
| best programming language available today as a personal
| project. However, it's true that what it has become today
| is now the work of many.
| agentultra wrote:
| A good deal of programming languages started out this
| way. A few that come to mind: C, C++, and Python.
| Javascript.
| proc0 wrote:
| > So are we saying that software engineering can be at odds
| with your ability to write code?
|
| This is absolutely the case and my main struggle as a SE.
| In my opinion this is all arbitrary and companies could
| easily structure themselves to allow engineers to focus on
| what they do best, instead of adding a ton of overhead with
| tasks that someone else that is not trained as an engineer
| could do. The response seems to always be the same and
| boils down to "you need to add business value and that
| includes all these other easy but time consuming tasks".
|
| I seriously doubt that is the only way, but I haven't build
| a large software company so ultimately it is hard for me to
| say, however I suspect that if an engineer's time is
| maximized to practice engineering, it would bring a lot
| more business value in the long run.
| UncleMeat wrote:
| 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.
| matt_s wrote:
| If we use a house building/construction analogy, in this
| comment chain we're saying software engineering is
| inclusive of house design/architecture down to wall
| construction, plumbing, electrical, etc. Following that
| analogy then I think when Xeoncross is asking about
| "hardcore engineering" that really would equate to new
| engineering products for the house building industry -
| like some new tech like solar roofing shingles (instead
| of raised solar panels).
|
| There aren't a lot of companies that are doing that in
| software. For example, there are a lot of SaaS businesses
| doing things that might have interesting engineering
| problems to solve but those engineering problems usually
| don't result in creating new products for software
| engineers to use. Rails is a good example of a byproduct
| from a SaaS business, React is a byproduct of whatever
| Meta does.
| SimonPStevens wrote:
| > 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.
| brianm wrote:
| 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 wrote:
| > 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.
| NBJack wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| onion2k wrote:
| _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.
| emrah wrote:
| > Something I learned relatively late in my career was that
| really impressive work is the result of iterations in tiny
| steps.
|
| I agree 100%
|
| > 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.
|
| This is the "if my grandma had four wheels, she would be a
| truck" argument and in my experience it is not accurate. A
| quote from Ratatouille puts it very eloquently: "A great chef
| could be anyone, but anyone could not be a great chef"
|
| > They're not that different to the rest of us
|
| I beg to differ. Again, with the caveat of "in my
| experience", they are very different. Maybe not in ways that
| would make a great Forbes article, like having superhuman IQ,
| but for example "having grit" or simply "ability to obsess
| over the right things" is a key ingredient that most people
| don't have enough of.
| mywittyname wrote:
| 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.
| coliveira wrote:
| There is a simple reason why megacorps don't spin off
| projects: they would need someone with vision to search for
| these projects and with high authority to proceed on the
| spin off. They don't have this kind of people, for the
| obvious reason that it is not their main concern.
| Executives in any megacorp are 100% busy making the core
| business a success, and investing time in small projects
| that may come to nothing is just a distraction. This may
| just explain why big corporations are just a waste of time
| and resources, in the long term.
| diceduckmonk wrote:
| > They don't have this kind of people
|
| Because the people with vision and conviction would be
| running their own startups
| diceduckmonk wrote:
| FWIW, the founder of HashiCorp created Vangrant when they
| are in college.
|
| Why did Terraform end up being the dominant product?
| Product-market fit. That's not just engineering, but
| bringing to market a product at the time when people need
| and understand it. This includes marketing and educating.
| Also, Terraform has an ecosystem of prebuilt providers. NPM
| as a package manager is not as well designed as other
| systems, but it's arguably been the most successful. While
| the internal prop tech you mentioned may be more advanced,
| it's not obvious you had the right product people with
| vision to build out that ecosystem. Most managers and
| product people at large companies aren't tech savvy beyond
| buzzwords
| withinboredom wrote:
| I could have a really cool time-travelling database to sell
| you, but I can't because I signed away my right to invent.
| So, if you really want to
|
| > built by the engineer who decides to venture on their own
| and replicate what they were building as a stand-alone
| product.
|
| We need to change our contracts.
| fiddlerwoaroof wrote:
| I think this is the key: employment contracts/ip policies
| should be designed to encourage spinning off internal
| projects (that are 'distractions' front he core product)
| as separate business units or as open source projects.
| glitchc wrote:
| That's an unfair characterization. You are low-balling the
| creativity, discipline and bureaucracy management ability
| these individuals bring to the table. The right circumstances
| are only part of the acquisition. Aptidude and attitude are
| the other parts.
| nonethewiser wrote:
| > Something I learned relatively late in my career was that
| really impressive work is the result of iterations in tiny
| steps.
|
| I think you are right. Really impressive work is generally
| the result of a longer journey than you realize. The time and
| effort put into it is probably underestimated. But my mind
| immediately tries to think of exceptions (which totally prove
| the rule). I'm curious if others would agree with this one:
| Sometimes there are just really great ideas.
|
| Minecraft comes to mind. And I don't mean today's Minecraft.
| I mean the alpha and beta versions which were wildly popular
| and essentially just an engine and sandbox world with a tiny
| fraction of the features today's game has. People have
| recreated that core game many times with fairly trivial code,
| which is why I attribute this more to "great idea" than long
| iterative process that most people cant replicate. And a
| totally anecdotally and subjective reason (although I've
| heard others express it too). I found the game immediately
| nostalgic. It was new but it felt old - like it had existed
| in some form before but had just now taken shape. That to me
| seems like a great idea.
|
| Ironically, I find myself questioning if I underestimated how
| long Notch took to create it. A cursory search says a week
| for the initial version, but this timeline shows more like 1
| to 1.5 years from nothing to alpha: https://minecraft-
| timeline.github.io/ Even still, the fact that the core game
| can be recreated without too much effort does suggest that
| that it was more about being a good idea than being difficult
| to implement. I don't look at Minecraft and think "wow I
| could never do this." Instead I look at it and think, "Wow.
| That was a really great idea."
|
| Although I suppose you could says that great ideas are an
| iterative process too. But at that point you have to decouple
| "really impressive stuff" from "I could never do this".
| withinboredom wrote:
| > People have recreated that core game many times with
| fairly trivial code
|
| Yes, because they have something to reference. It was like
| Notch took a level editor and made it into the game itself.
| That isn't an easy thing to figure out and takes time.
|
| > Sometimes there are just really great ideas.
|
| Ideas are easy and usually it's really stupid ideas that
| turn out to be great ideas. Who would think that an FPS
| level editor would be a good idea? Or a text box that
| anyone can edit on a profile page would be popular
| (facebook)?
|
| There are not great ideas, just ideas that are executed
| well.
| nonethewiser wrote:
| >> People have recreated that core game many times with
| fairly trivial code
|
| > Yes, because they have something to reference.
|
| But you couldn't reimplement podman in a few hundred
| lines of code.
|
| > Ideas are easy
|
| Not all ideas have the same quality. Should be self
| evident. Nevertheless you should be able to see that I
| understand ideas are cheap in some sense - that's what
| the comment about decoupling "this was an iterative
| process" from "I could never do this." You can transfer
| an idea effortlessly - it's more about implementing it.
| But if its it trival to implement clearly more of the
| brilliance was on the idea side of things.
| withinboredom wrote:
| > But you couldn't reimplement podman in a few hundred
| lines of code.
|
| You don't even need a few hundred:
| https://github.com/p8952/bocker
|
| And then there's 'dokku' which IIRC, started as a bash
| version of Heroku.
|
| > Not all ideas have the same quality.
|
| They really do. I've heard all kinds of things in my
| career, but almost none I would want to dedicate a
| portion of my life building. Not because they are bad
| ideas or won't work, but because of the person with the
| idea or it just didn't interest me. Those people went on
| to be moderately successful (like hundreds of millions
| worth) but I'm glad I wasn't on that ride.
| nonethewiser wrote:
| That would prove my point though. If it actually is that
| easy to implement then podman is more in the "good idea"
| than complicated implementation category as well.
| Bjartr wrote:
| > Notch took a level editor and made it into the game
| itself. That isn't an easy thing to figure out and takes
| time.
|
| He built an infiniminer clone for himself when it was
| discontinued. It certainly grew into more than that, but
| that's where it started.
| timacles wrote:
| The thing that separates those guys from everyone else is
| simple.
|
| Its stamina.
|
| No there isn't some higher level of understanding or deep
| perception. Every one of the all time great programmers had 1
| exact thing in common with no exceptions. Stamina. You will
| not find a single outlier.
|
| They did their craft every day, for many hours, year after
| year.
|
| So sure, any of us could have taken the individual small
| steps. But when you look at a whole body of work, you'll see
| they're cranking through these "small steps" like the
| Juggernaut running through walls for decades
| sibeliuss wrote:
| This is the answer. There's certainly ridiculous talent
| (especially with ideas), but in my experience it always
| comes down to stamina stretched through time. Cool things
| get built by people that stick it out, and recruit others
| to do the same. And also know _exactly_ when to exit to
| pursue something new (but that's a different subject).
| tltimeline2 wrote:
| Interesting, is the ability to know when to exit a
| prerequisite? I would think there's a distribution
| between those you spoke of and some that just picked one
| thing and went forever.
| biscuits1 wrote:
| Stamina isn't the word I would go for. It would be
| commitment. For those that have loads of stamina, it's the
| commitment to continuous creative encounters that leads to
| the perceived magic.
|
| From "Courage to Create" by Rollo May: "It is said that the
| novelist Thomas Wolfe, who was one of the highly creative
| figures of the American scene, that he was a "genius
| without talent." But he was so creative because he threw
| himself so completely in the material and the challenge of
| saying it-he was great because of the intensity of his
| encounter"
|
| Apologies going philosophical, its the only way to debate
| such an answer-science has no real answers for this title
| we call "staff engineer"
| er4hn wrote:
| "Nothing in this world can take the place of persistence.
| Talent will not; nothing is more common than unsuccessful
| people with talent. Genius will not; unrewarded genius is
| almost a proverb. Education will not; the world is full
| of educated derelicts. Persistence and determination
| alone are omnipotent. The slogan "press on" has solved
| and always will solve the problems of the human race" -
| Calvin Coolidge
| cjsplat wrote:
| And with Coolidge's great persistence, he helped build
| the foundation for the Great Depression.
|
| It is possible to "press on" in the wrong direction.
| brookst wrote:
| Yes. Determination is essential for success but does not
| guarantee success.
|
| Kind of like how virtually all great cooking requires
| salt, but use of salt goes not guarantee a great dish.
| raydev wrote:
| Sure, but we're talking about "persistence" and
| dedication on the scale of "I built a complex piece of
| software"
| [deleted]
| mkozlows wrote:
| 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.
| opportune wrote:
| 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.
| lhorie wrote:
| 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 wrote:
| > 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.
| hgsgm wrote:
| Why are your people asking so many bad questions?
|
| Good questions are "how can we X?" And good answers are
| "here's how: Y"
|
| Then the asker decides if they are willing and able to Y.
| VirusNewbie wrote:
| 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.
| personjerry wrote:
| 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)
| alistairSH wrote:
| 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]"
| closeparen wrote:
| 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.
| groby_b wrote:
| 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.
| pkaler wrote:
| 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!)
| coliveira wrote:
| > 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 wrote:
| > 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 wrote:
| 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 wrote:
| Most companies are not "good" engineering companies. They
| are at best mediocre.
| proc0 wrote:
| 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.
| greenthrow wrote:
| Have you read the book in question? The whole point of it is
| that it is not a manager position.
| YesBox wrote:
| >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
| lifeisstillgood wrote:
| 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".
| zerr wrote:
| 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.
| coev wrote:
| Doug Crockford was "Distinguished Fellow Engineer" or some
| title like that at Paypal.
| skeeter2020 wrote:
| 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.
| bradlys wrote:
| > Your company might have a written definition of what good
| engineering means - written values, and engineering principles.
| But the clearest indicator of what the company values is what
| gets people promoted.
|
| This is really the takeaway you should have. Be observant of what
| is actually rewarded. Companies are made of people. Unless you're
| in some ultra bureaucratic government position that is 100%
| impossible to get around - the guidelines are not really that
| important.
|
| Instead, it's all about your relationship with your management
| chain. If your management chain likes you (the reason why doesn't
| matter) then that's all that really is important to your progress
| in your career. You can be more impactful than any employee, add
| to the bottom line of any business meaningfully, and still get
| fired because your management chain doesn't like you. And vice
| versa - seen folks do nothing to add to the bottom line or make
| any impact and yet - promos come their way.
|
| Getting to staff and beyond is entirely about politics. It has
| little to do with your actual work. I'd highly recommend finding
| an organization that aligns to you. If you feel like an outsider
| in your company - switch companies until you find one where you
| feel accepted. If this is not possible (and it often enough isn't
| possible) - then ask if it's worth it and start wearing a costume
| and play whatever part you think will get you further. (Even with
| this attitude - it might still not be possible to advance. We
| live in a unjust world.)
| bgirard wrote:
| > Put non-meetings on the calendar
|
| I'd love to do that. But once you throw in real meetings, no
| meetings days, PTOs, time zones it becomes difficult to schedule
| a work meeting because now there's no overlapping block of time
| when you need to meet. Now all meetings get pushed out even more
| and the calendar time required for certain tasks increases.
| dboreham wrote:
| Allow read access to your calendar for teammates and instruct
| them to override your "Thinking time" slots in situations where
| the matter is urgent.
| 1024core wrote:
| That's what I do, and it works very well.
| bgirard wrote:
| There's several issues with this:
|
| * I work with too many people to reasonably instruct them of
| this preference and expect them to follow it.
|
| * The definition of urgent is highly subjective. What's
| urgent to one person isn't to someone else.
|
| * Some will be more aggressive and book over it, while others
| will be more passive/shy like junior engineers. You're now
| further rewarding aggressive behavior over passive behavior.
|
| But more importantly non-urgent meetings are still important.
| If everyone does this then the minimum turn around time for
| engineering tasks needing help/consensus between 3 engineers
| goes up from a few hours to a few days. You compensate this
| by juggling more tasks.
|
| I think in practice the downstream problems are much worse
| than the original problem you're solving. I prefer to just
| decline any meetings that aren't a good use of my time.
| kevan wrote:
| Everything in moderation I suppose. I've experimented with
| marking large blocks (2-4hrs) as tentative for IC work a couple
| days/week recurring and it does help avoid the Swiss cheese of
| 30m meetings spread across the entire day.
|
| Lately for a 1-3 day horizon I've been adding everything I'm
| working on as blocked. That definitely helps me visualize my
| priorities for the next couple days and whether I have room to
| fit more meetings or tasks. The main downside is I'm used to a
| more free-flowing schedule where I pick a task based on how I'm
| feeling.
| 0xbadcafebee wrote:
| This is a feature, not a bug. Most meetings could have just
| been an e-mail or a slack thread. They don't want to spend 20
| minutes writing an e-mail, so instead they spend an hour in a
| meeting where they find out they still need to spend 20 minutes
| thinking about something and writing it up. People need to
| learn to work without meetings. Open Source projects get work
| done with virtually no meetings at all.
| 1024core wrote:
| The best time to put such "non-meetings" on your calendar is
| when you switch teams. You're new and the meeting vultures
| haven't noticed the new piece of meat yet.
|
| I switched teams a year ago and quickly blocked off 2-3 hour
| slots every day as "focused work time". It's been a godsend for
| my sanity.
|
| Edit: typo
| auntienomen wrote:
| My favorite version of Staff Engineer is "Person whose prospects
| for career advancement are limited by their seniority, who is
| consequentially incentivized to care about doing the right
| thing".
|
| Least favorite version is the one who doesn't realize this, and
| makes a muddle of an already working system to demonstrate their
| impact.
| 1024core wrote:
| These are some of the things I wish were taught in school (maybe
| grad school, maybe in software engg disciplines). Including
| things like "how to write a great design doc", etc.
| czbond wrote:
| This is all thats required of staff engineers? Heck, at the big
| consulting firms, senior associate engineers had to do all this
| to get promoted to manager.
|
| [context: senior associates were 1 step from the bottom rung]
| omginternets wrote:
| This is a collection of highlights from a book, so I don't
| think it's "all that is required of staff engineers."
___________________________________________________________________
(page generated 2023-05-17 23:00 UTC)