[HN Gopher] On Being a Senior Engineer (2012)
___________________________________________________________________
On Being a Senior Engineer (2012)
Author : rspivak
Score : 121 points
Date : 2024-08-18 12:42 UTC (3 days ago)
(HTM) web link (www.kitchensoap.com)
(TXT) w3m dump (www.kitchensoap.com)
| comprev wrote:
| Needs (2012) in the submission title
| malfist wrote:
| The article opens with a standard trope of "the generations after
| me are bad" and builds their arguments from there. Not sure much
| value should be placed on this article
| jspaw wrote:
| Thanks for the feedback!
| delichon wrote:
| To me being a senior software engineer means that when your
| production system goes unstable from gremlins or cosmic rays or
| other mysterious sources of chaos and the business that pays for
| your food is in jeopardy, there's nobody to pass the buck to. You
| just have to buckle down and figure it out or update the resume
| and start working on your excuses or apologies to newly
| unemployed coworkers and their families.
| Vinnl wrote:
| Well, except for perhaps to a staff engineer. Or a senior staff
| engineer. Or a principal engineer. Or maybe a senior staff
| principal engineer? The VP of Engineering? The CTO?
| bux93 wrote:
| a vendor
| zelphirkalt wrote:
| Vendor is a trump card in this game. Surely no one can do
| better than a vendor, from which we buy a solution! Best of
| all, we can then shift the blame too! Our customers cannot
| use our product? It is the vendor's fault!
| bravetraveler wrote:
| Don't forget the venerable Financial Institutions and
| their cousin, Insurance
| consf wrote:
| So is it not just about coding but also about owning the
| issues?
| spacephysics wrote:
| To me senior means ownership above everything else.
|
| Owning a part of the system implies that you'll do (or
| organize) the risk analysis of new features, cost-benefit of
| bug fixing, coding (or at least outlining the design),
| support via documentation, communicating to product
| owner/stake holders/support.
|
| Elevating from senior to staff (or principal etc) would be
| projects with larger scope, moving parts, and higher
| risk/reward.
|
| I think its easier to see a junior to senior (if say we have
| two buckets).
|
| After senior it gets tough. Does their role involve purely
| tech lead/coding? Or some managerial politics, pushing
| engineering culture/direction in whichever way is best for
| the company.
|
| Really depends on the company itself, which I think is why
| it's hard to standardize.
|
| CTO at my own startup? Really a glorified senior dev with
| some communication and business mixed in. Upper senior dev at
| Netflix? Most likely masters or PhD level (not necessarily
| with the degree) understanding of some C.S. concepts that
| matter at that scale.
| neilv wrote:
| > _The tl;dr on trade-offs is that everyone cuts corners, in
| every project. Immature engineers discover them in hindsight,
| disgusted. Mature engineers spell them out at the onset of a
| project, accept them and recognize them as part of good
| engineering._
|
| And if you are that "mature" engineer, you need to remember and
| realize that many relatively junior engineers and non-engineer
| stakeholders won't always understand why you're saying X, Y, and
| Z.
|
| So you'll have to figure out how to get sufficient shared
| understanding, or at least a lot of blind trust in your judgment.
| nevertoolate wrote:
| I like to introduce some form of ADRs (Architectural Decision
| Records) with some kind of decision making process based on
| consent decision making flow (stolen from Sociocracy)
|
| Implementation details of the process changes from context to
| context but clear communication is needed in all workplaces,
| making the implicit explicit.
| daliusd wrote:
| I like how this article is still relevant after 12 years. It gave
| me some ideas why I have some problems working with my colleague
| (as well senior level engineer).
| 000ooo000 wrote:
| >Avoiding responsibility for estimates is another way of saying,
| "I'm not ready to be relied upon for building critical pieces of
| infrastructure."
|
| There's potential for significant nuance in such a scenario and
| to reduce it to this silly quote hurts the piece, IMO.
| dbc_dvon wrote:
| The quote sucks and I completely disagree with the author.
|
| It puts the whole responsibility on the engineer to predict how
| long a thing will take. There are much better approaches
| though. We can focus on allowing the team to create lots of
| small tickets (can be done in a few hours or 1-2 days),
| massively improving our prediction estimates. The author seems
| to suggest we should be able to predict the future no matter
| the task or team communication/organization.
| daliusd wrote:
| I think you have misread quote here. Emphasis is on taking
| responsibility here IMHO. Your proposal to "divide and
| conquer" is still estimation process.
| consf wrote:
| It is complex and shouldn't be solely placed on the shoulders
| of the engineer
| yobbo wrote:
| But also, people are responsible for estimates from the first
| day of their career. It's the scope that changes.
| 000ooo000 wrote:
| I hope one day we all can realise that all of the pontification
| about the defining qualities of a 'senior' engineer, or the
| height at which the bar should be set, whether the bar has slowly
| been lowered over time, etc is all pointless. Senior or not
| senior is a lens useful only to HR and insecure engineers.
| bravetraveler wrote:
| Agree. I've only recently received a title with proper
| seniority. People have been looking to me for
| leadership/guidance for longer.
|
| A _' sufficiently capable'_ junior can run the show for a bit.
| I've been them, for better or worse. I'm great at the technical
| side but admittedly terrible at the 'softer' people aspect.
|
| Multitudes, yo. Thanks to a lot of incident management
| experience, I'm the Dictator you want when the sky is falling.
| _However_ , I'm absolutely best ignored when it comes to
| politics or making plans months out. My bias here is more
| apparent than normal, stability.
|
| Titles are made up, just like the rest. Trying to apply these
| too much is suspect
| cess11 wrote:
| Right, we should use the old apprentice, journeyman, master
| from the crafts.
|
| When a master says you're ready to independently take on
| customers and have what it takes to satisfy their needs you
| become a journeyman, and when you've practiced long enough to
| have pushed the boundaries of the craft and reliably do things
| that masters can learn from, then they might count you among
| themselves.
| Simon_ORourke wrote:
| You'd be surprised at how it's a great developer of latent
| narcissistic behavior. I know a couple of solid developers who
| immediate turned into outright jerks on promotion to senior.
| bitwize wrote:
| > I know a couple of solid developers who immediate turned
| into outright jerks on promotion to senior.
|
| I know a guy who became significantly more short-fused and
| less friendly when he was promoted into management. I don't
| think he liked management work, particularly when it involved
| both that _and_ fulfilling outstanding responsibilities as an
| IC because he was the sole SME for a variety of different
| products /systems we had. There were many sad-sounding
| conversations with his then-girlfriend well after close of
| business.
|
| Point being, sometimes people who turn into jerks when
| promoted are not necessarily narcissists, they just have a
| shitton more work to deal with now and/or are out of their
| element and/or can't get home to spend enough time with their
| SO/kids/pets to fully psychologically reset at the end of the
| day. I don't know how that description tracks with the devs
| you knew, though.
| bravetraveler wrote:
| Yes, exactly! Thank you for posting. I tried to get at this
| in my _[now-deleted]_ peer post... but failed to be nearly
| as effective. Was a shameful wall of text.
|
| Seniors are juniors with a label _and expectations_
| applied. It 's incredibly subjective of course. To your
| point, I find the conventional expectations of 'Senior' too
| high.
|
| I have spent decades perfecting my technical skill.
| Literally since childhood. My personal skills have
| suffered, neither I or you want me to be a talking head.
|
| The story of the Junior who doesn't get enough help is a
| bit self-fulfilling/lacking in context. How much has been
| given/stuck/to who? Hearing _' not enough'_ can either
| raise someone to the challenge, or create resentment.
|
| A bit of closing irony. I was fine with providing on-site
| training as a Senior until RTO was ham-fisted so poorly...
| that I found an even more illustrious _' Principal'_ title,
| and expectations, elsewhere.
| roenxi wrote:
| It links to a similar problem of measuring engineering
| productivity, which the industry cannot do.
|
| Notch wrote Minecraft when he was around 30. He didn't have 15
| years experience in professional engineering and it seems to me
| he mostly just mucked around writing games in his professional
| life. He's now recognised as creating more than a billion
| dollars in value.
|
| Is a "senior" engineer doing better than that at creating
| software? Did he ever make senior? Does he exhibit all the
| traits of a senior engineer in the article like not having an
| ego? This is a profound challenge to the entire industry. The
| title really is just for HR, a developed ability to choose what
| projects should be worked on is much more important and there
| is a big gap between a Senior Software Engineer and someone who
| actually writes great software.
| locuscoeruleus wrote:
| On the flip side, the code that he originally wrote would
| never scale to a billion dollars. It was wildly inefficient.
| Someone with a bit more experience as a game developer,
| someone a bit senior if you will, was necessary to turn the
| idea into what it is today.
| cma wrote:
| Who? They only did have a handful of people when they sold
| for $1 billion. Were any senior devs?
| philipov wrote:
| I think it would be fair to call Jens the Principal
| Engineer on Minecraft. Is that senior enough?
| zimpenfish wrote:
| > It was wildly inefficient.
|
| Spoiler: Minecraft Java Edition is still wildly inefficient
| despite having a trillion dollar company backing it for 10
| years.
| gilleain wrote:
| Wildly? I'm sure the code might be inefficient in many
| ways, but there have (as I understand) been performance
| improvements such as in chunk loading and map generation.
|
| Even the latest (apparently controversial) recent
| redstone update is meant to take account of performance -
| https://www.minecraft.net/en-us/article/minecraft-
| snapshot-2...
|
| "The performance impact of Redstone wire (connected
| blocks of Redstone Dust) has been improved"
|
| I've no idea how true that statement is, of course!
| zimpenfish wrote:
| > performance improvements such as in chunk loading and
| map generation
|
| True but the general game loop is still (wildly)
| inefficient; hence the multitude of performance mods
| (Sodium, Lithium, FerriteCore, ImmediatelyFast, etc.)
| that are considered basic mods for anyone wanting to play
| the game without dipping down to tragic fps.
|
| All of that functionality could (and should!) have been
| folded into the Minecraft source years ago. But Microsoft
| didn't buy Minecraft to give people a good experience -
| they bought it because it generates a non-trivial amount
| of money from things like Bedrock IAPs, merch licensing,
| etc. Updating the games is just a necessary evil that
| keeps the money flowing.
|
| (Bedrock, on the other hand, is much more optimised
| because, IIRC, the core game was written in C++ targeting
| mobile devices and needed to be efficient to even work.)
| fhd2 wrote:
| When I ran bigger companies in the past, I gravitated towards
| defining whether someone is entry level, junior, mid level or
| senior _entirely_ based on experience measured in time. And
| their salary was a function in which that was the primary
| factor.
|
| The problem with any internal definition of "senior" is that
| it's misaligned with the market. If you pay someone less than
| their market value, they're likely to leave for a place that
| appreciates them more. If you pay someone above their market
| value, you're basically putting golden hand cuffs on them. I'm
| not saying I never did those things, but I did have almost
| exclusively bad experiences with both of these situations. And
| I've hired something like 200 developers in my CTO roles.
|
| If I have a senior whose salary I'm reluctant to raise, I
| wonder about three things: Do they actually have enough
| experience to be in that bracket? Is that person perhaps just
| not a good fit for what we need? Do I perhaps have too high
| expectations in seniors that made me inflate their salaries?
|
| If I have a junior whose salary I want to raise, I think about
| similar questions, but I also wonder if that person perhaps
| went above and beyond and a bonus is more fitting than a
| permanent raise.
|
| Sounds a bit cold and rigid, and of course there's exceptions
| to any rule, but this guiding principle has served me best over
| the years.
|
| Creating my own, literally made up and company specific, job
| description for a senior has pretty universally back fired. My
| company isn't a special snowflake that gets to invent their own
| job market. It's much more reasonable to connect to the actual
| job market.
|
| As for titles, I usually didn't put "junior" or "senior" in
| them at all as far as I could get away with it. For the most
| part, my seniors were fine, many even happy, with this.
| chiefalchemist wrote:
| > Is that person perhaps just not a good fit for what we
| need?
|
| That's The Critical question. That is: the situation needs X
| (read: combo of hard tech skills and soft skills). Can they
| deliver X and then some?
|
| If not, there's three choices:
|
| 1) Develop them to fill their deficiencies, if they're
| interested.
|
| 2) Communicate with them that the biz has evolved and the fit
| is a misfit. This happens with founders who evolve into CEOs
| and don't have the chops for that role. It happens.
|
| 3) Do nothing.
|
| Note: A seasoned employee will always be asking the same
| questions. That is: is this the place for me. Should I stay
| or go?
|
| Great leaders and managers are aware of the mutualness of the
| relationship and approach it from that pov
| usrusr wrote:
| > As for titles, I usually didn't put "junior" or "senior" in
| them at all as far as I could get away with it
|
| So instead of golden handcuffs, you apply lead handcuffs,
| forcing them to lie in their resume if ever they have to
| apply elsewhere after the day they age out of the slim age
| bracket in which they would be accepted at anything below
| senior?
| teqsun wrote:
| > the slim age bracket in which they would be accepted at
| anything below senior
|
| What is that age bracket, in your opinion?
| Chyzwar wrote:
| Some people never reach Senior level, both on skill level and
| impact. Judging someone level purely on time is a sure way to
| promote incompetent and lose talent that is developing faster
| than average. Organization promoting mediocrity, where people
| are awarded with random bonuses instead of opportunities.
|
| How can you expect anything substantial from senior
| developers if you promoted them purely on experience measured
| in time?. How anybody would be motived if they can just wait
| for promotion? How can hire people on senior positions if you
| do not have internal metrics for these positions? How can you
| get rid of underperformers?
| akomtu wrote:
| Senior engineer is like a fuel efficient car - it's a meaningless
| marketing term used to distract attention from what matters - the
| pricetag and fuel consumption in hard numbers.
| pistoleer wrote:
| Are there ways to quantify the qualities of engineers, or any
| "human resource" in hard numbers? What are interesting
| qualities in particular?
|
| Maybe salary, which is influenced by location as well as
| negotiation prowess and just plain chance.
|
| Or maybe "experience", which is actually "years gainfully
| employed" and is at best a proxy for experience.
|
| IQ could be a something to profile on. Which is a proxy for
| intelligence by measuring ability to recognize patterns.
|
| Number of Github stars then? Which is really influenced more by
| marketing of the project than how good the code is.
|
| Perhaps they have good stories or anecdotes. But that's not
| really a hard number.
| yobbo wrote:
| Since one person can never be held liable to agree with
| another's definition of "seniority", it is just a subjective
| term.
| Tade0 wrote:
| I've skimmed over the article and much of it appears to be what
| was pounded into our (student) heads in college - it just took us
| time to start applying it.
|
| Anyway, I have my own definition and it's "a person who realized
| that they've already forgotten stuff they used to know by heart
| in their junior years and approach every problem with appropriate
| humility stemming from said realization".
|
| My "knowledge window" is, as I discovered, 9 years the skill that
| I've lost which established this was the ability to write an SQL
| statement - even a simple one.
| zerr wrote:
| One common misconception about senior engineers - akin to
| "promotion to management", some assume that seniors should be
| non-ICs (non-individual-contributors), should "multiply" their
| force "upon" others, organize and attend lots of meetings,
| "across departments", work on PowerPoint presentations, mostly do
| such non-coding tasks, because "only coding is so junior"... This
| is a good way to alienate real senior engineers who just enjoy
| engineering. It is perfectly valid to be IC
| senior/staff/principal/fellow engineer.
| HL33tibCe7 wrote:
| Senior engineers generally should have a force multiplicative
| effect. "IC" doesn't mean "work in a silo interacting with
| nobody ever". But I agree that many orgs have a problem
| measuring this and focus on BS.
| Xcelerate wrote:
| A bit of a cynical take (on Hacker News no less) but after being
| in the industry for a while, my view is that the best definition
| of "level" is self-referential: it corresponds to the ability of
| a person to convince others that they are at that level.
|
| I also have a definition of what I think level should ideally
| represent: the marginal contribution of a person's influence on
| the outcome of a company, relative to the counterfactual
| situation where that person never worked there, adjusted for a
| specific threshold of risk tolerance.
|
| In other words, you can consider two hypothetical futures for a
| company: one with a specific person and one without that person.
| You then have a probability distribution defined over the
| difference in outcomes. For someone at a very high level, the
| absolute area under this curve is large--they have a big impact
| on the company (whether positive or negative). For someone at a
| lower level, their impact is small.
|
| Someone who is _good_ at their job should hopefully lead to
| positive impact, but you can certainly adjust this for risk.
| Perhaps you bring in a CEO who has a 90% chance of tripling the
| company's revenue /growth and a 10% chance of leading the company
| to failure. That might be acceptable for a hypergrowth startup.
| For a larger and more mature company, you might have a different
| risk profile.
| carlmr wrote:
| >I also have a definition of what I think level should ideally
| represent: the marginal contribution of a person's influence on
| the outcome of a company, relative to the counterfactual
| situation where that person never worked there, adjusted for a
| specific threshold of risk tolerance.
|
| Doesn't this tie back to the self-referential nature. If you
| can convince others of your "level", then you can also affect
| more change, making the level self-fulfilling, too.
| thehappyfellow wrote:
| I think you are basically right, in many organisations you
| get a lot of influence based on your title and not on your
| skill.
| baq wrote:
| Skill is hard to verify. Title is used as an easy to verify
| proxy _by design_. It 's a feature.
|
| How the feature is implemented in different
| organizations... is a different topic entirely.
| thehappyfellow wrote:
| I get that, but even if titles were an amazing proxy for
| skill, that will only correlate with some subset of
| skills and say nothing about the rest (e.g. some staff
| engineers are amazing technically and only pretty good as
| team leads or vice versa). Even assuming that title
| correlates well with some notion of skill, there are
| organisations which won't allow someone with Fancy Title
| to make a decision requiring skill C if they're bad at it
| - and some would have no way of stopping them.
| axus wrote:
| The word "title" makes me think of noble titles. Hard to
| earn, but easy to hang on to.
| Xcelerate wrote:
| Yeah, I hesitated to mention that as the post was already
| getting a bit long. I've always wondered what would happen if
| you took a random high performing junior engineer and just
| immediately gave them control over a large part of the
| company. Or vice versa--a level 8 engineer pretends to be a
| junior engineer and joins another company at level 3.
|
| I suspect the degree of comfort and familiarity that people
| have in these situations has a lot to do with their potential
| to influence company outcomes. The junior engineer would
| still have very little impact when immediately given a VP
| role and likely proxy their decision-making through others at
| that level, but they would learn to adapt much quicker than
| someone going slowly from level 3 to 4 to 5, etc. (assuming
| the pressure didn't cause them to quit). There's a reason
| people say joining a startup accelerates career growth at the
| next company.
|
| On the other hand, the level 8 engineer would immediately get
| themselves invited to discussions at a higher level, because
| they already have the social skills required to interact in
| those meetings. It's not that most junior engineers can't set
| up these meetings on others' calendars--it's that they don't
| want to because they know they'll stand out like a sore thumb
| in the discussions.
|
| There's definitely an element of luck involved with being in
| the right situations so you have the opportunity to make a
| larger impact, and once you do, you're more comfortable with
| putting yourself in situations where you can do that again.
| So it is self-fulfilling in a sense. But there's also a
| personality component, as more ambitious people (at least
| within the context of a corporate environment) are willing to
| take on more risk of embarrassing themselves by potentially
| failing at a higher level.
| yobbo wrote:
| Hypothetically, anything can happen.
|
| A "senior" cosplaying as junior can easily turn into
| conflict and deadlock when people feel their toes being
| stepped on by someone beneath them.
|
| A junior cosplaying as senior reflects a situation with
| nepotism or favouritism. They are typically routed-around,
| quietly, by the people with relevant competence and jobs to
| do.
|
| Real _believable_ seniority is actually important in
| eliminating friction.
| JamesSwift wrote:
| You've semi reinvented WAR (wins above replacement)
|
| https://www.mlb.com/glossary/advanced-stats/wins-above-repla...
| LudwigNagasena wrote:
| They've actually described the marginal revenue product of
| labor. In general, all of those counterfactuals fall under
| the concept of opportunity costs.
| JamesSwift wrote:
| Its also very similar to '+/-' in basketball
| closeparen wrote:
| Isn't the counterfactual there an N-1 headcount, rather
| than a replacement-level worker in the same slot?
| ryandrake wrote:
| It probably doesn't matter as long as you keep it
| consistent. If the counterfactual was N-1 instead of a
| replacement worker, then almost everyone would represent
| positive value, and you're still comparing multiple
| positive numbers. Yes, there exist people who are net
| negatives and the company would be better off without
| them, but not THAT many.
| sokoloff wrote:
| I think there are many employees who are net negatives
| (who create less value than their full cost to the
| company). Sometimes this relates to the employee; many
| times it relates to the circumstance the employee finds
| themself in. (In almost any spiraling downward company,
| there are many employees in this situation, through no
| particular fault of their own.)
|
| There are far fewer who are gross negatives (who
| contribute negatively overall, before compensation and
| other costs).
| candu wrote:
| > ...it corresponds to the ability of a person to convince
| others that they are at that level.
|
| One note on this: as your career progresses, your ability to
| convince others around you that you're at a certain level goes
| from being unimportant to important, and then from there to
| essential.
|
| After all, you need to influence others to do just about
| anything that involves more than yourself - and developing that
| power of influence is very much a skill in and of itself (see
| [1] for instance: it takes a lot to deliver even a simple,
| clear decision effectively!)
|
| [1] https://randsinrepose.com/archives/mandate-dissect/
| anytime5704 wrote:
| Maybe this is a semantic distinction, but I'd say "your
| ability to convince people (period)" is what becomes more and
| more important.
|
| Levels really shouldn't factor into a problem discussion
| beyond determining who is involved in the discussion to begin
| with.
| ryandrake wrote:
| > Levels really shouldn't factor into a problem discussion
| beyond determining who is involved in the discussion to
| begin with.
|
| Titles shouldn't matter but they very often do. Question:
| "How should we integrate our product X with product Y?"
| Answer: "VIP David mandated that all integrations use
| technology Z, so it's already decided."
| game_the0ry wrote:
| > A bit of a cynical take (on Hacker News no less) but after
| being in the industry for a while, my view is that the best
| definition of "level" is self-referential: it corresponds to
| the ability of a person to convince others that they are at
| that level.
|
| I agree on paper that this is a great heuristic, but an
| employer would be more than happy to pay you a junior or mid
| compensation while extract senior level contributions from you.
| I see your point, though, and I agree for the most part.
|
| > In other words, you can consider two hypothetical futures for
| a company: one with a specific person and one without that
| person.
|
| This another tricky one - I agree on principal but I have seen
| this not work out in practice. For example, I have seen very
| senior people leave suddenly (like no notice period) and the
| business does not even skip a beat. In some cases, things get
| more efficient. My point being - employee level and comp
| sometimes do not map to contribution + business value.
|
| That being said, I observed the above at big companies, where
| inefficiencies can hide in multiple levels of hierarchy and
| bureaucratic red tape. Its also why I hate working at big
| companies.
| saghm wrote:
| > I agree on paper that this is a great heuristic, but an
| employer would be more than happy to pay you a junior or mid
| compensation while extract senior level contributions from
| you. I see your point, though, and I agree for the most part.
|
| In some ways, this actually makes sense to me. In my opinion,
| senior versus junior engineer seems like it should be about
| the skills and abilities of an individual, whereas one's
| compensation and actual title depend on a lot of
| environmental circumstances (company politics, for lack of a
| better term). While "soft skills" are an important part of a
| senior engineer, I'd argue that the set of soft skills useful
| to an individual contributor engineer doesn't necessarily
| overlap a ton with the soft skills needed to be able to
| effectively secure a promotion and/or higher compensation;
| navigating the corporate bureaucracy to the benefit of the
| team is primarily the responsibility of the manager. Finding
| a way to express the "level" of an engineer separately from
| their situation at their current company doesn't seem that
| crazy to me.
| fifilura wrote:
| > For example, I have seen very senior people leave suddenly
| (like no notice period) and the business does not even skip a
| beat.
|
| Maybe that senior was great at training their replacement?
| fifilura wrote:
| Ok, I'll guess I'll double-down since I am getting
| downvotes and it is still on topic.
|
| I would be proud of someone said that about me. I have
| introduced new technologies (that work well) but I have
| also spent a significant amount of time training juniors,
| that I now know could handle the stack without me. Much
| because of their hard work of course, but a little bit
| because of me.
|
| Maybe I was a one-trick-pony and this is all I knew. Or
| maybe I would continue improving the products by
| introducing new ways of working or implementing great stuff
| in the future.
|
| Neither of this will be noticeable in a future without me.
|
| But the worst kind of senior ought to be people that leave
| suddenly, leaving a chaos behind them.
|
| It is like the "hero" who creates a chaotic product and
| puts a 100 hour week of bugfixing just before the release.
|
| Compared to the person who just plans a product and
| executes according to schedule without leaving a mark.
|
| What do you prefer?
| game_the0ry wrote:
| > Maybe that senior was great at training their
| replacement?
|
| No, this was not the case. It turned out that those folks
| that left just did not contribute beyond superficial
| "management", delegating to subordinates, coordinating
| emails. Sort of like a "team secretary".
| trelane wrote:
| > an employer would be more than happy to pay you a junior or
| mid compensation while extract senior level contributions
| from you.
|
| The problem with this argument is that the level also gets
| you a seat at tables you otherwise don't get invited to. The
| places where the decisions get made.
|
| So "senior contribution" is not always possible without
| having the senior level on paper.
| game_the0ry wrote:
| Debatable.
|
| I have seen "senior" people hired from outside that do not
| make the same level of contributions as some one who is
| less senior by title and has years of tenure at their
| current position.
|
| This is super common bc many companies would rather hire
| from outside instead of promoting from within. Also why
| there is so much turn over (engineers last for like 2-4
| years then move on).
| saghm wrote:
| > In other words, you can consider two hypothetical futures for
| a company: one with a specific person and one without that
| person. You then have a probability distribution defined over
| the difference in outcomes. For someone at a very high level,
| the absolute area under this curve is large--they have a big
| impact on the company (whether positive or negative). For
| someone at a lower level, their impact is small.
|
| Sounds a bit like the concept of "wins above replacement" as a
| baseball stat (https://www.mlb.com/glossary/advanced-
| stats/wins-above-repla...), which attempts to calculate how
| many fewer (or more, in the case of negative value players) a
| team would have if instead of a given player, they had someone
| producing the exact average of the league.
| Wheaties466 wrote:
| >I also have a definition of what I think level should ideally
| represent: the marginal contribution of a person's influence on
| the outcome of a company, relative to the counterfactual
| situation where that person never worked there
|
| What you are describing here is actual a stat they try to
| quantify in sports. W.A.R. Wins above replacement.
|
| It is often used in MVP race talks.
| charlie0 wrote:
| >A bit of a cynical take (on Hacker News no less) but after
| being in the industry for a while, my view is that the best
| definition of "level" is self-referential: it corresponds to
| the ability of a person to convince others that they are at
| that level.
|
| This is right here is one of my biggest concerns at the moment.
| I know my technical skills are just as good as (if not better
| than) most of my peers with more YOE on paper, yet my
| communication skills are below them.
|
| I really enjoy doing the technical stuff, but now I'm not so
| motivated to keep picking up technical skills because I've hit
| diminishing returns on it and instead now have to focus on
| something I don't like, nor have been great at for the longest
| time, and those are communication skills.
|
| I do wonder if these skills are mutually exclusive to a large
| degree. ie, the thing that makes my peers better at
| communicating is exactly the same thing that makes less
| technical and vice versa. I worry about never being able to
| level up my comms skills without also taking my technical
| skills down a notch.
|
| For me, I'm resigned to just looking for a new job to get a
| salary increase vs doing something I enjoy less, improving comm
| skills.
| szundi wrote:
| Fwiw I was the CEO of my startup (obviously?). I could not
| even get why people are fighting each other, I was so naive
| and bad at communication.
|
| Now I'm called a supercommunicator at the same company just
| because I took it seriously and took attention and vigorously
| checked out results of my communication attempts.
|
| Yeah it was like 10 years, but first 1-2 with this mindset
| started with almost panicking to despair to be interesting to
| have more and more success. Now I almost enjoy it when I
| don't think about how this is about fighting enthropy and
| finding out who is silly in what way later to counteract
| that.
|
| Might be even fun.
|
| Edit: most fun part when you just became quite good and got
| it and the troublemakers are forgot you on the loser shelf,
| trying baby level politics stuff on you just because they are
| lazy. Yeah, then you can root them out and have a nice
| company.
| charlie0 wrote:
| I get were you are coming from. Focusing on comm skills is
| a big branch of a decision tree in terms future paths
| because it opens up possibility of joining the managerial
| class (CEO/CTO being potential options).
|
| What convinced me against going down this branch for the
| time being is a quote from Naval Ravikant.
|
| > No one can compete with you on being you. Most of life is
| a search for who and what needs you the most.
|
| If I really enjoy tech stuff and not comms, I should focus
| on the tech stuff. Of course, I still need to have a good
| baseline at comms, but it doesn't have to be great.
| spacephysics wrote:
| What are some of the politics stuff you mention?
|
| I've been a senior engineer (definition loose) at a company
| I work at, and owner of a side business start up.
|
| Politics at the startup are a bit easier, less than 10
| people and such. But at the large company I'm trying to
| make sure I'm not caught off guard and be taken advantage
| of/other toxic politic stuff.
| rsanheim wrote:
| I think it is a trap to assume that communication skills and
| technical skills are mutually exclusive. In fact, many of the
| best engineers I've ever know were _also_ some of the best at
| communicating their ideas.
|
| Granted, dysfunctional orgs, particularly large ones, will
| always end up promoting the sort of person I think you have
| in mind -- those who talk a great game, play politics, but
| don't really ship. That is an organizational and culture
| problem, though, and doesn't mean you should ignore your
| "soft" skills.
| jvanderbot wrote:
| It's tempting to tell yourself you would be doing a
| disservice by learning to be a better communicator. After
| all, why give up technical skills?
|
| When framed that way, it just seems completely obviously
| false.
| ozim wrote:
| I think what you are looking for is what interests people.
|
| Skills are not mutually exclusive but I suppose you are much
| more interested in technical stuff and to learn communication
| you have to become interested in other people.
|
| I am also mostly interested in learning technical details of
| some software or system and not that much in what someone did
| with his time last weekend.
|
| So what makes people better communicators is mostly that they
| are interested about other people and other people opinions
| and other people mood.
| charlie0 wrote:
| Yes, this is exactly what I'm getting at. In theory, those
| two are not mutually exclusive, but in practice they very
| much are due to personal preferences and that will shape
| what you become good at.
|
| Of course, there are definitely people who excel at both,
| but they are outliers. Most will only get/want to excel in
| one of those two things.
| OrigamiPastrami wrote:
| > Perhaps you bring in a CEO who has a 90% chance of tripling
| the company's revenue/growth and a 10% chance of leading the
| company to failure.
|
| I realize these are hypothetical numbers, but they're so
| clearly backwards. It's more like a 10% chance for tripling the
| growth with a 90% chance of failure, and even that is being
| optimistic.
| jvanderbot wrote:
| Well now they're hypothetical _and_ polarizing!
| austin-cheney wrote:
| That depends on the changes proposed. Many places I have
| worked at could apply simple bits of internal automation and
| training that easily allows for trimming, or repurposing,
| half or more headcount. Keep in mind software is a cost
| center, so changes to tech teams will never result in greater
| revenue but they can greatly reduce expenses.
| gumby wrote:
| > A bit of a cynical take (on Hacker News no less) but after
| being in the industry for a while, my view is that the best
| definition of "level" is self-referential: it corresponds to
| the ability of a person to convince others that they are at
| that level.
|
| This is of course not just in "the industry" -- for an extreme
| example there are a lot of elections arund the world in 2024
| and almost all of them have at least one candidate trying to
| convince the hiring team (i.e. the voters) that they are
| qualified to do a job they've never done before.
| Matzvyk wrote:
| With experience and full-stack development, everyone is becoming
| a solo, individual contributor. They only collaborate, when
| necessary, due to time constraints. This leads to developers
| becoming isolated and superior, making them special and
| different. They are the only ones who have built things, while
| others are just there to support them. I've seen this phenomenon
| in many companies, where senior developers are not bound by the
| 24-hour clock and are always available. This is the reality of
| progress, where individuals become so skilled that they are the
| only ones who can do certain tasks. However, I respect the
| competition, but having multiple senior developers in a product
| company can lead to conflicts. I don't why it is but it is
| everywhere and making things tough for others to take decisions
| where you are only at the quest of these such Sr Devs.
| aswerty wrote:
| > In general, mature engineers are comfortable with working
| within some nonzero amount of uncertainty and risk
|
| Just to take that sentence as a snapshot. I find the opposite is
| more relevant in the software field. Essentially, being solicited
| for an estimate on something where the certainty and
| predictability on what is being built is approaching zero.
|
| There is no doubt the "softness" of software engineering as
| opposed to other forms of engineering is very distinct. To the
| point where there is an overarching question on whether it is
| engineering at all. This has resulted in the iterative Agile
| development process competing with, if not overtaking, the
| Waterfall development process that exists in other engineering
| disciplines.
|
| And in software "engineering" the practical steps of construction
| are as intellectual an activity as the design. Where in other
| disciplines the design is considered an intellectual activity and
| the implementation is not.
|
| I'm not going anywhere particular with this train of thought -
| other than surfacing the risks in comparing software development
| to traditional engineering.
| valenterry wrote:
| The difference between software developement and "other forms
| of engineering" is that you can copy software rather easily,
| but you cannot copy a bridge. If you could engineering would
| have the same issues in estimation.
|
| In fact, take any engineering project that cannot be copied
| (like a new, big, custom airport) and you'll quickly see how
| much worth those "classical engineering estimations" really
| are.
|
| A mature developer cannot magically give a better estimation.
| What they can do is communicate better, understand the value of
| POCs and which parts of a project to tackle first to reduce
| uncertainty as early as possible, as well as correctly
| describing uncertantity (e.g. NOT with a single number).
| jajko wrote:
| A lot of delays in engineering projects are caused by various
| political pressures, changes coming in the middle for
| whatever reason, natural or other physical disasters/events
| impacting physical construction way more than software
| development. Or new regulations complicating things more than
| previously thought.
| thehappyfellow wrote:
| A frequent form of lack of tolerance for risk I've seen is not
| being able to make a speed vs quality trade-off. One example:
|
| We were rolling out a change that had a small risk that we'll
| have to manually reboot a couple of machines. The total
| disruption to business would've been less than $10k for sure. I
| had to fight people who wanted to spend 3 months writing a one-
| ff tooling lowering the chance of it happening. Madness!
| perrygeo wrote:
| Fairly common, especially with mission-critical
| infrastructure like databases. There's an implicit
| assumption, by engineers and managers alike, that 100% uptime
| is the gold standard and anything less is a failure. It takes
| a rational engineer (in the context of this discussion,
| usually a "senior") to point out that a) SLAs never promise
| 100%, b) the rest of the infrastructure that comprises the
| system has only a few nines of availability anyways, c) the
| engineering cost of getting from 99.99% to 100% is orders of
| magnitude higher than getting to 99.999%. In other words:
| senior engineers should be able to contextualize engineering
| work and do tradeoff analysis; they provide value not by
| doing _more_ work but by skipping the expensive, low-impact
| work.
| bongodongobob wrote:
| $10k in lost sales/product during the downtime or $10k + the
| cost of IT to stand things back up, verify, resync + cost of
| other departments manually fixing other adjacent things that
| broke?
|
| People who don't work daily in infra tend to not understand
| that downtime like that can have massive ripple effects. That
| one server, unknown to you, might have tentacles that reach
| all over the company. It might generate 100 tickets that now
| need to be verified by various IT personnel over the next few
| days _in addition_ to their likely already full workload. It
| might have fucked up backups, DFS, patching cadence etc etc.
| thehappyfellow wrote:
| Sure, the approach I advocated for can have much worse
| consequences in general. However, in this particular case
| it was ~impossible for the outage to get that costly - we
| operated the servers and knew the blast radius. My estimate
| was for the total cost.
|
| Also, 2 engineers working for 3 months cost a ton of money,
| not even counting for the opportunity cost of other things
| they could've been doing. If the potential outage cost was
| closer to $100k I'd likely stick with my decision.
| austin-cheney wrote:
| In my experience, especially in web development, senior developer
| just means excellent with boilerplate and an awareness of many
| tools. Thats it.
|
| The problem is nobody bothers to define competency and very few
| people can actually program for the web. I mean almost nobody.
| Countless times here on HN I have had hiring managers tell these
| people don't exist.
|
| The way I would define competence in web development is super
| simple:
|
| * Can you program in JavaScript. I do not mean React, Vue,
| jquery, or other abstraction bullshit. I actually mean can you
| program in that language, as in writing original software. This
| eliminates about 95% of developers.
|
| * Can you program outside the browser in any language? This can
| still be JavaScript via Node or Deno but it could also be Go,
| Python, or Java.
|
| * Do you understand transmission debugging for HTTP, WebSockets,
| session management, and messaging as an event?
|
| The problem is most developers can at least half way accomplish
| the second bullet point and then attempt to fake the rest. It's
| like toddlers playing pretend, which is why everything in both
| the startup world and corporate world are generally the same
| copy/paste spa app. Copy/paste is about all the developers can
| do.
|
| There are many developers that can do much more, but work culture
| often seems hostile to originality and so they keep it to
| themselves for side projects.
| pproe wrote:
| Why stop there? If you can't write your own browser engine or
| router firmware, are you really competent enough?
| austin-cheney wrote:
| If you can't program why pretend to be a programmer? What
| could possibly go wrong?
|
| JavaScript is not assembly and life isn't so hard to warrant
| the level of sympathy asinine comments like this expect. I am
| merely suggesting people should know how to do what they
| claim, and clearly they cannot. I have no sympathy for that.
| snapcaster wrote:
| A lot of this list seems like gatekeeping as opposed to things
| actually relevant for most software engineering jobs
| austin-cheney wrote:
| That depends upon expectations set by leadership. I wouldn't
| call someone who can't do more than copy/paste React
| boilerplate any kind of engineer. At a bank everyone who is
| more than a junior employee wears the title Vice President,
| but almost none of those people are even in management.
|
| The choice employers must make is whether it's cheaper to
| overpay for someone who cannot do what they are hired for or
| spend the extra time waiting for someone who can. So the flip
| side is that hiring programmers that can't program is
| gatekeeping for the hiring managers.
| strken wrote:
| One very unfortunate thing when it comes to title inflation is
| the concept of a terminal level. Bigger tech companies don't let
| you just sit around and write code unless you're at a certain
| level, usual senior. This turns senior engineer into a de facto
| "this employee is competent enough not to fire if next
| performance review is meets expectations" title.
| pradn wrote:
| Google changed their terminal level to L4, which is a level
| where you can be do designs with guidance, and implement big
| chunks of projects on your own. The previous terminal level was
| L5 ("senior"), where you're expected to own multi-quarter long
| projects and be a tech-lead of ~5-10 people. Oddly it does end
| up being structured as a pyramid - lots of L3/L4 folks than L5
| folks.
| oneepic wrote:
| Many "senior engineers" are BS and are just posturing. To be
| honest, this idea alone has been really, really hard for me to
| understand personally. I learn a lot by watching other people
| work, and I spent way too much time seeing people posturing when
| I really should've been watching kind, responsible, vulnerable,
| open-minded people with values.
| ilc wrote:
| Level ends up depending on two things:
|
| Skill - Do you have the raw skills to do the task at hand.
|
| Scope - What scope are you doing that task at.
|
| Example:
|
| - Setting up a single file server for your team, pretty easy, low
| effort.
|
| - Setting up a file server / SAN to hold corporate data.
|
| - Designing file servers for the core of your business
| operations.
|
| - Doing that for a vendor, where your software and architecture
| choices will impact possibly impact N companies.
|
| (Ironically the last two are closer than you think.)
|
| But it isn't about setting up the file server software, it is
| about the scope, the size of the team you are likely leading, the
| impact of the decisions etc. Automation, repeatability, etc...
| Actually architect the thing instead of winging it...
|
| The bigger the numbers get... the bigger the title, and the
| better, you better be, both as an engineer and as a human,
| willing to accept that you are wrong, and find that better
| answer... People are relying on you to deliver.
| dzonga wrote:
| the forever - hamster. I don't want to be senior engineer. I want
| to be an owner.
___________________________________________________________________
(page generated 2024-08-21 23:01 UTC)