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.
> 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.
> 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.
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).
> 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.
> 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".
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.
> ...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!)
> 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."
>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.
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.
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.
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.
They've actually described the marginal revenue product of labor. In general, all of those counterfactuals fall under the concept of opportunity costs.
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.
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).
>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.
> 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.
>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.
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.
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.
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.
This encapsulates a hunch I've had lately: that you could probably tell a lot about a potential hire if you could read their emails and slack messages.
The best co-workers are good at communicating without being annoying or a jerk, they have a good sense of what the important issues are, and they don't let ego or trivial concerns get in the way of solving problems.
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.
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.
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.
> 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.
> 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.
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.
> 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.
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!
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.
$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.
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.
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).
> you can copy software rather easily, but you cannot copy a bridge
You can copy a bridge just as easily as you can copy software: just print another copy of the blueprints. Just change the header from the name of one project to another, and you're done with the engineering at that new site. What's that, the span length is different? The soil is different? The traffic patterns and weather patterns and political climate and regulations are different? Of course they are. And when you copy source code, the use case is different, the hardware is different, the database is different, the inputs are different, the client is different. Every engineering job is custom. Software and bridge. The two disciplines are not as different as you say.
Bridge engineering also undergoes an "agile" methodology as the plans are repeatedly changed during conversations with the client, discovery of new regulations, ground-truthing, etc. Remember: the outcome of engineering is plans, not a finished product.
You're talking about differences in constructing the thing, after the engineering is complete. That's largely irrelevant to the engineering cost.
Now you have copied the blueprint, but not the bridge. (and before you complain that software is also just a blueprint, the difference is: in one case you estimate the blueprint and not its execution, in the other case both (or even just the execution)
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.
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.
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?
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!
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.
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.
I think you have misread quote here. Emphasis is on taking responsibility here IMHO. Your proposal to “divide and conquer” is still estimation process.
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.
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.
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.
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
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 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).
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.
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.
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.
You're right that the roles are somewhat flexible: somewhere between raw technical output and technical/design leadership and "program/project management".
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.)
I generally agree, but I think it's more subtle than that. Levels and titles aren't really about productivity per se either, they're about defining role expectations and conferring authority to ICs in a corporate environment where there are hundreds or thousands of developers, and they are inextricably linked to the communication needs that dominate productivity in large organizations. They often don't even map between departments, let alone different companies, and especially at smaller companies that don't have the headcount for any meaningful calibration to exist.
From that lens, Notch's "level" when he created Minecraft is pretty much undefined. He obviously had technical and entrepreneurial skill, which gave him huge credibility, and is a fast-track to a certain title / level at acquisition time, but that says very little about his ability to meet the expectations of a Microsoft engineer that worked their way up to that level through promotions.
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.
> 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
Absolutely! But I also see a fourth option: Just make an exception. Just because you make exceptions doesn't mean your system sucks. If you make exceptions most of the time, it probably does, but I had to make them rarely.
It doesn't sound like good management, and perhaps it isn't, but I did have people that didn't entirely meet my expectations stay, without gratuitous raises of course. I'd be open about this with them: "I think it'd make sense for both of us if you worked elsewhere, and I can help you figure out where that could be and how to get there. But I'm also gonna offer you a path here if you want it."
Sometimes that turned out to not be a good decision. Sometimes it was. But I felt it was a humane solution to the problem, that exceptional situation. No manager is all-knowing enough to understand to 100% what value they're getting out of each individual employee, so it's not the most illogical thing to involve them in that decision. But more than anything, I'm not a fan of changing a system that works for the general cases to deal with rare and varied edge cases. That's premature generalisation, and I think both in software and in organisations, that is the root of all evil.
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?
Exceptions exist. Sometimes I might want to hire someone with a lot of experience who doesn't provide value relative to that, I can still do it, but be very transparent about that with them. Experience in itself is valuable regardless of whether or not I can find a little system that quantifies that for me. And another important question is: Should seniors really earn that much more than juniors? Those are the kind of questions I ask myself before making exceptions.
If you have someone very experienced with a high market value who doesn't really pay off in terms of what value you can extract from them, it can make sense to look into an exit - or an exception.
With the amount of people I managed in the past, I rarely had to make exceptions. Your mileage may absolutely vary though, and there's certainly no one-size-fits-all solution. Management is hard, easy solutions and "best" practices rarely exist.
> Exceptions exist. Sometimes I might want to hire someone with a lot of experience who doesn't provide value relative to that, I can still do it, but be very transparent about that with them. Experience in itself is valuable regardless of whether or not I can find a little system that quantifies that for me. And another important question is: Should seniors really earn that much more than juniors? Those are the kind of questions I ask myself before making exceptions.
Seniors can do things that are hard or impossible for juniors. A good senior developer can bootstrap a project to MVP, establish best practices, onboard and mentor juniors/mid, communicate effectively with stockholders. Senior can manage technical debt and help with estimation and roadmap. Even on purely technical output, they can be few times more efficient than juniors. Many people will fail to learn these skills even after many years working as developers. Experience is important, but overall it is a smaller part of the overall skill set of a developer. I know plenty of people of 10+ years of experience that are just mid level developers and will stay this way.
> If you have someone very experienced with a high market value who doesn't really pay off in terms of what value you can extract from them, it can make sense to look into an exit - or an exception.
If you do not have metrics other than experience, then how you can know what value to expect? I get the feeling that you hired senior developers and then put them into mid/junior level roles and responsibilities. Value that you get from senior developers depends on opportunities that you give them.
> With the amount of people I managed in the past, I rarely had to make exceptions. Your mileage may absolutely vary though, and there's certainly no one-size-fits-all solution. Management is hard, easy solutions and "best" practices rarely exist.
That there reason why software in Europe losing to US. You decided on an easy solution to measure developers by experience in years instead of actual output. You want to extract value instead of create a value. Furthermore, you also do not want to pay senior developers because you do not understand the unique value that they can bring to the table.
> 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?
I generally didn't pay pay seniors all _that_ much more than the juniors. And I happily hired people >60 in the past. It's not linear, it someone has 10 years, 20 years or 50 years experience, they're in the same senior range. Depending on how much they can bring to the table, I can increase their salary within that range, not purely based on age. Experience in years just tells me what range to put them in, not where in the range. I fear I haven't made that clear at all in my parent post, sorry about that.
The way tech worker ageism works is that many employers would never consider offering someone with a few years of experience (even if it's just life experience) little money. It's either a generous offer of the full package or a pass. And if previous employers skipped on the titles game ("my job description said 'programmer'"), the chance for anything other than "pass" is miniscule at employers who take titles as a given (and where people could not possibly imagine a world without).
That's what i meant: the titles don't have to mean anything in your company, but if you don't hand them out, even if only as a meaningless formality without any consequence, you're making life unnecessarily hard for employees when they need to look elsewhere. That's why i called it lead handcuffs: it makes leaving more difficult. And i don't get the impression that it's an intentional strategy ("yay, less fluctuation! Let's call them all junior janitors!"), that's why i was pointing out this aspect of "no junior or senior".
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.
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
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.
> 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.
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.
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.
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.