The lowest expectations of senior developers are that they can run a project and lead a small team to bring the work to life. They’re stable and consistent. They’re rarely stumped by technical problems and, even when they are stumped, they have the tools to get themselves unstumped. They don’t lose their composure or resolve just because they don’t know the answer and it’s not revealing itself without a struggle.

Human limitations play a significant part in who becomes a senior developer. Even more so in deciding who becomes very senior. A hard truth is that you have to be pretty clever to make the cut as a senior developer. You have to be able to handle high amounts of complexity and ambiguity. These take the form of technical implementation details, team coordination, and tradeoffs of all sorts. Many people don’t get excited by that kind of work and even some who are excited by it simply can’t do it. Looking up from the bottom of the senior rungs of engineering ladder, the number of people in such roles gets smaller and smaller with every step. Maybe 1/3 of everyone who ever starts out as a junior will ever make it to senior. The falloff as you look towards “staff engineer” or “principal engineer” is much, much greater. At a company like Facebook which has thousands and thousands of engineers, fewer than 10% make up the top brackets of their engineer ladder.

That said, the day-to-day reality of being a senior developer is mostly about good judgment. In fact, good judgment is at least as important as technical abilities in the senior level. You often find senior engineers who are no more technically skilled than strong mid-level engineers. The difference between them will be that the senior engineer uses good judgment in choosing exactly the right problems to solve. She keeps the team motivated and focused. She delivers. Her mid-level counterpart might lack literally every one of those qualities, despite being just as good as a coder.

Every senior engineer learns the skill of giving the people around her some room to struggle, but always with guard rails. She learns the art of deciding when to intervene and when to let people toil.

When her mid-level teammate says, “I’m going to dive into solving <this interesting problem that I’m excited about>!” Her brain does the computation: “When we spend a month on that problem, we still won’t have solved this other blocking problem… but the abstraction you’re proposing could really pay down some technical debt… Hm… Okay. Worth it.” She probably does and says nothing. Instead, she watches the magic unfold.

When she hears, “Ugh… I hate this stupid application. It makes no sense,” her mind automatically translates it as, “I’m a junior engineer and I’m getting frustrated because this is really hard. I need an encouraging nudge in the right direction.”

When she hears one of the mid-level engineers on her team exclaim, “If we switched to using <some hot new library>, our code would be so much cleaner,” she might feel an ache in her bones that says, “Even if that new library was made of solid gold, it wouldn’t be valuable enough to warrant the weeks of refactoring. And, should you want to know the real blockers in our codebase, here’s a prioritised list that’s been keeping me up at night: …”. Here, maybe she nudges that engineer in the direction of something that would really help the team without costing weeks of refactoring.

In each of these scenarios, the skills the senior engineer is applying are: perceptivity, discernment, and leadership. Note that all of them are technical, even the emotional support to the junior. Because the senior engineer is very technical, she can tell the difference between frustrated complaint and legitimate technical grievance. When someone gets a senior title, but not senior technical abilities, they lack this perspective. In those teams, often technical decisions are made that result in lateral movements or even worsening of the existing tech. How do you know if someone’s bold new initiative is worth it or not? Good senior engineers do the brain work to figure it out.

The last point I’ll make about senior engineers is that they don’t make messes. This can be technical messes or interpersonal messes. This is sometimes described as “the first rule is that you figure out the rules.” Some folks will chafe at this. It might seem unfair. It might seem like senior engineers are meant to be psychic. How are you meant to know what is expected of you if no one takes the time to explain it? The counterpoint to this is that there are usually countless ways to deduce the correct expectations. Doing so requires the senior engineer to observe much, much more than she engages. She has to be mentally and emotionally poised enough to think several steps ahead of her actions, anticipating their outcomes. She might feel just as outraged by a management decision as her junior engineer peers. Yet she’ll mostly be silent about it, where the junior and mid-level engineers might rage and cause interpersonal chaos.

Her less-senior counterparts are not wrong, they’ve just misunderstood how real influence is asserted. The senior engineer thinks about how to create the outcome she wants without causing undue drama along the way. This often means she bites her tongue when she’d love to lash out. Among very senior engineers you’ll often find extremely strongly held opinions. What you also find is that these engineers think very, very carefully about how to bring those opinions to bear within a team. If the senior engineer causes offence and backlash, she’s failed at being effective in her role. She’s likely to be just as driving and revolutionary as people who are a hundred times more visible. The levers she chooses to pull are the ones that lead to the necessary changes, often without anyone ever needing to breathe a word about it. Most mid-level and even entry-level senior engineers miss this.

Senior Coder Caricaturisation

A fun detail about senior engineers is that they exhibit a huge diversity in skills. Most junior and mid-level engineers go through the same struggles and very similar growth trajectories. By the time those engineers become senior, they’ve found their passions. They’ve also learned what working styles they connect most with. Because of this, there’s a really neat diversification that happens at the senior level.

One of the most important distinctions is that some senior engineers drift toward project leadership and others drift towards deep technical mastery. The sorts of engineers excel at project leadership tend to build stronger interpersonal skills. They tend to acquire more mastery of navigating the org chart of their company. At building consensus. At communicating and promoting their work. Most technology project don’t require deep tech. Most projects just require a vision for the outcome and steady progress toward it. Especially in larger organizations, the obstacles are interpersonal or political. Many senior engineers specialise, really, in navigating these treacherous waters, delivering projects consistently. Sometimes they’re successful despite their company.

The other sort of senior engineer tends to drift towards elite levels of pure technical ability. They’re the people who know how their code works all the way down to the machine instructions. They’re the ones giving incisive code review that makes other senior engineers pause to say, “Whoa.” These sorts of senior engineers inspire the people around them, but not because of their powerful presence in meetings or their rallying presentations. Instead, they inspire people because they achieve technical outcomes that shock and delight. These are the sorts of people who led the way on Machine Learning as a discipline. The sort of people who create world-changing libraries like React. Or for that matter who invent programming languages like Rust. Often these engineers operate very near to academia, taking theoretical tech and turning it into applied tech. To this ilk of programmer, there is no such thing as topping out in terms of coding ability or technical mastery.

There exists a tiny subset of senior engineers who do both of these things. They tend to be the sort of people you see on stage at major tech events. They’re the leaders of influential open source projects. People like Andrei Alexandrescu and Rob Pike come to mind for this rare intersection.

The distinctions run deeper than these two broad buckets. Listed below are some coarse categories of engineer that show up in the senior echelons. These categories have hazy boundaries. Think of it as a very crude K-modes across engineering personalities in order to surface the clearest subgroups.

The All ‘Rounder

The most common form of senior engineer is The All ‘Rounder, sometimes called ‘full stack generalist’. She’s the sort of engineer that can make good progress on building new systems or maintaining old systems alike. She can solve hard bugs across the stack. She can give solid code review feedback. She can break down tasks and delegate to folks junior to her. She’s the kind of engineer you’ll happily hire as many of as you can because they show up and make good things happen consistently.

A subset of these folks will drift into people management. Especially at startups, it’s not uncommon to see a tech lead serving in a managerial role. Likewise, a subset of these engineers will drift towards product and/or project management. They’ll have the perspective and people skills to effectively lead a team in delivering a technical outcome like a new product or a new piece of infrastructure.

It’s not uncommon to see All ‘Rounder engineers bouncing between people management and tech lead roles. Between TPM roles and senior engineer roles. Their core skillset includes deep technical knowledge, solid interpersonal/communication skills, and deep pragmatism with respect to getting things done. Because of this, they have a lot of ways of offering value within their company.

The Code Whisperer

This brand of senior developer focuses most or all of her energy on navigating an existing problem space, making things better. She finds bugs and jagged edges that need honing deep within the machine. Her work is almost exclusively technical and largely individual. This type of engineer likes diving deep into the technical weeds, discovering the brilliance and sins of engineers past, like a code archaeologist. When there’s a problem no one else can explain, this person is usually the one to call. When left to their own devices, they discover fixes and optimisations that blow away other engineers. They might produce a quarter of the work of their brethren, but that work’s impact tends to be many, many times more valuable.

The Earth Mover

Some senior engineers love moving heaven and earth. They like taking old broken down systems and turning them into new ones — the hard way. The love taking a vague problem area and writing all the code to solve it. They want hard problems to solve. They want technical complexity. But most of all, they want to deliver output. They may or may not be good at rallying teams, but they certainly inspire their team by relentlessly plowing through hard tasks. They’re good at managing big, complex, multistep refactors. They’re probably less technical than “The Code Whisperer” but they’re also much, much more productive.

The Domain Expert

Some senior engineers will find their calling by losing themselves in some technology. Maybe it’s databases. Maybe it’s machine learning. Maybe it’s operations. The Domain Expert tends to be really, really good in a narrow area. They often play critical roles on their teams because their knowledge is desperately needed for the success of the whole. Incidentally, hiring a Domain Expert is tricky unless you already have one in the same domain. Successful Domain Experts within a team tend to offer their knowledge constantly to others. Code reviews. Tech talks. They tend to raise the bar around the team within their area of specialty.

What comes after “senior” ?

Levelling up within the “senior” bracket of engineer is largely a function of what type of engineer you are. Each of the coarse categories described above has its own career progression. However, as you go from senior to even more elite statuses like “staff” engineer or “principal” engineer the common factor is that you’re consistently offering greater and greater value to the company. Solving more important problems. Enabling other developers to work smarter or faster. Saving the company from big problems when few others (or in some cases when no others) could help.

First degree senior developers tend to lead a small teams of coders. More senior engineers can offer value by tech leading larger projects, rallying larger teams of engineers behind them. Or by gaining deeper technical knowledge allowing them to solve problems other engineers can’t. Or by playing a key role in delivering technical outcomes over and over again. Exploring how to evaluate very senior engineers is a pretty interesting topic that warrants its own detailed write up, so I’ll leave off the topic here.