On Being a Senior Engineer (2012)
kitchensoap.com
kitchensoap.com
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.
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.
How the feature is implemented in different organizations... is a different topic entirely.
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.
https://www.mlb.com/glossary/advanced-stats/wins-above-repla...
There are far fewer who are gross negatives (who contribute negatively overall, before compensation and other costs).
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 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.
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?
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?
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".
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).
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.
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.
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.
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.
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.
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.
When framed that way, it just seems completely obviously false.
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.
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.
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.
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.
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.
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.
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 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.
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!
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.
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.
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.
There's potential for significant nuance in such a scenario and to reduce it to this silly quote hurts the piece, IMO.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Implementation details of the process changes from context to context but clear communication is needed in all workplaces, making the implicit explicit.
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
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.
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.
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.
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.
Spoiler: Minecraft Java Edition is still wildly inefficient despite having a trillion dollar company backing it for 10 years.
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!
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.)
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.
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.
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
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.
Do they not want ppl able and ready to learn? Does the market not change? Is the dynamics of the org that ridgid?
Sometimes ya just gotta go with what ya got (and toss in some individual and team development). It will never ever be perfect.
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?
What is that age bracket, in your opinion?
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".
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?
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.
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.
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.