10 ms·

On Being a Senior Engineer (2012)

155 points by rspivak 2y ago

deleted 2y ago
[deleted]
comprev 2y ago
Needs (2012) in the submission title
malfist 2y ago
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
- MrDresden 2y ago
  The only mention of generations in the article comes from an initial quote, which describes how the quoted party has anecdotally experienced many of a specific generation wanting to climb the seniority ladder in a very quick time. The rest of the article then goes on to explore what the depth of knowledge and maturity of behaviour should preferably be for anyone claiming to be a senior engineer. It does so without ever referencing generations again. I think this is a worthwhile read.
- jspaw 2y ago
  Thanks for the feedback!
delichon 2y ago
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 2y ago
  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 2y ago
    a vendor
    - zelphirkalt 2y ago
      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 2y ago
        Don't forget the venerable Financial Institutions and their cousin, Insurance
      - deleted 2y ago
        [deleted]
- consf 2y ago
  So is it not just about coding but also about owning the issues?
  - spacephysics 2y ago
    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 2y ago
> 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 2y ago
  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 2y ago
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 2y ago
>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 2y ago
  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 2y ago
    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 2y ago
    [dead]
- yobbo 2y ago
  But also, people are responsible for estimates from the first day of their career. It's the scope that changes.
- deleted 2y ago
  [deleted]
000ooo000 2y ago
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 2y ago
  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 2y ago
  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 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - bitwize 2y ago
    > 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.
akomtu 2y ago
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 2y ago
  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 2y ago
    Since one person can never be held liable to agree with another's definition of "seniority", it is just a subjective term.
Tade0 2y ago
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 2y ago
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 2y ago
  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 2y ago
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.
- JamesSwift 2y ago
  You’ve semi reinvented WAR (wins above replacement) https://www.mlb.com/glossary/advanced-stats/wins-above-replacement https://www.mlb.com/glossary/advanced-stats/wins-above-repla...
  - LudwigNagasena 2y ago
    They've actually described the marginal revenue product of labor. In general, all of those counterfactuals fall under the concept of opportunity costs.
    - JamesSwift 2y ago
      Its also very similar to '+/-' in basketball
    - closeparen 2y ago
Matzvyk 2y ago
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.
deleted 2y ago
[deleted]
aswerty 2y ago
> 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 2y ago
  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 2y ago
    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.
  - feoren 2y ago
austin-cheney 2y ago
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 2y ago
  Why stop there? If you can't write your own browser engine or router firmware, are you really competent enough?
  - austin-cheney 2y ago
    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 2y ago
  A lot of this list seems like gatekeeping as opposed to things actually relevant for most software engineering jobs
kattin9483 2y ago
[flagged]
strken 2y ago
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 2y ago
  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.
  - titanomachy 2y ago
    This used to be accurate, but is out of whack now that the big players have scaled back junior hiring so hard. My team (like many others around me) is all L5/L6, everyone writes code and there is less opportunity to lead/direct others since everyone is quite independent. Even a few years ago, many L5s were more like rock-solid ICs than what I would consider “tech leads”. And an L5 tech-leading 7-10 people I would consider to be an L6 who just hasn’t gotten promoted yet.
    - pradn 2y ago
      You're right that the roles are somewhat flexible: somewhere between raw technical output and technical/design leadership and "program/project management".
oneepic 2y ago
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 2y ago
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 2y ago
the forever - hamster. I don't want to be senior engineer. I want to be an owner.

155 points by rspivak 2y ago

deleted 2y ago

[deleted]

comprev 2y ago

Needs (2012) in the submission title

malfist 2y ago

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

MrDresden 2y ago
The only mention of generations in the article comes from an initial quote, which describes how the quoted party has anecdotally experienced many of a specific generation wanting to climb the seniority ladder in a very quick time. The rest of the article then goes on to explore what the depth of knowledge and maturity of behaviour should preferably be for anyone claiming to be a senior engineer. It does so without ever referencing generations again. I think this is a worthwhile read.
jspaw 2y ago
Thanks for the feedback!

delichon 2y ago

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 2y ago
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 2y ago
  a vendor
  - zelphirkalt 2y ago
    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 2y ago
      Don't forget the venerable Financial Institutions and their cousin, Insurance
    - deleted 2y ago
      [deleted]
consf 2y ago
So is it not just about coding but also about owning the issues?
- spacephysics 2y ago
  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 2y ago

> 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 2y ago
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 2y ago

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 2y ago

>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 2y ago
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 2y ago
  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 2y ago
  [dead]
yobbo 2y ago
But also, people are responsible for estimates from the first day of their career. It's the scope that changes.
deleted 2y ago
[deleted]

000ooo000 2y ago

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 2y ago
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 2y ago
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 2y ago
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.
- deleted 2y ago
  [deleted]
- bitwize 2y ago
  > 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.

akomtu 2y ago

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 2y ago
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 2y ago
  Since one person can never be held liable to agree with another's definition of "seniority", it is just a subjective term.

Tade0 2y ago

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 2y ago

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 2y ago
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 2y ago

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.

JamesSwift 2y ago
You’ve semi reinvented WAR (wins above replacement) https://www.mlb.com/glossary/advanced-stats/wins-above-replacement https://www.mlb.com/glossary/advanced-stats/wins-above-repla...
- LudwigNagasena 2y ago
  They've actually described the marginal revenue product of labor. In general, all of those counterfactuals fall under the concept of opportunity costs.
  - JamesSwift 2y ago
    Its also very similar to '+/-' in basketball
  - closeparen 2y ago

Matzvyk 2y ago

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.

deleted 2y ago

[deleted]

aswerty 2y ago

> 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 2y ago
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 2y ago
  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.
- feoren 2y ago

austin-cheney 2y ago

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 2y ago
Why stop there? If you can't write your own browser engine or router firmware, are you really competent enough?
- austin-cheney 2y ago
  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 2y ago
A lot of this list seems like gatekeeping as opposed to things actually relevant for most software engineering jobs

kattin9483 2y ago

[flagged]

strken 2y ago

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 2y ago
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.
- titanomachy 2y ago
  This used to be accurate, but is out of whack now that the big players have scaled back junior hiring so hard. My team (like many others around me) is all L5/L6, everyone writes code and there is less opportunity to lead/direct others since everyone is quite independent. Even a few years ago, many L5s were more like rock-solid ICs than what I would consider “tech leads”. And an L5 tech-leading 7-10 people I would consider to be an L6 who just hasn’t gotten promoted yet.
  - pradn 2y ago
    You're right that the roles are somewhat flexible: somewhere between raw technical output and technical/design leadership and "program/project management".

oneepic 2y ago

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 2y ago

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 2y ago

the forever - hamster. I don't want to be senior engineer. I want to be an owner.