The developer you are today is a cleverer, more capable version of the developer you were yesterday. The scope of task you can handle today is ever so slightly bigger and more challenging than your peak yesterday. It’s one of the most exciting aspects of becoming a software engineer. The career progression opportunities are massive. Likewise, the satisfaction you can get from solving very hard problems goes right up to the edge of as-yet unsolved problems by any human. For example, human eyes had never actually seen a black hole until Dr. Bouman plied her craft to create an algorithm to do it. Not a lot of industries have this quality. It’s quite special.
A related aspect of working in tech is that your professional level is independent of many factors that would decide your career growth in other industries. For instance, you don’t have to be 10-years-senior in your career to be a ‘senior’ programmer. Likewise, being a developer for 10 years doesn’t make you senior by default. You don’t have to have diplomas and accreditations to do the work. You just have to have the skills and be able to demonstrate them.
Honestly, it’s perhaps the thing about the technology industry that I love the most. Nepotism might make you the foreman on a construction site or the manager of a restaurant, but it won’t help you understand how to scale a poorly architected codebase. Tech is far from unbiased, but it’s significantly meritocratic compared to many other fields.
The fact that great people can progress very quickly can also make it hard for people to know where they are in their journey. Not every team knows how to nurture its rising stars. Not every manager knows how to foster someone who is stuck between two levels. What this post aims to do is give some clarity about the different software engineering levels in terms of skills and performance. About team dynamics and independence. If you’re lost in a world of “We’re seeking developers with 5+ years of experience,” it might offer you a counterpoint that focuses on what you’re actually capable of rather than some arbitrary tenure.
A brief aside about terminology: In this post and in general, I’m going to use the terms “developer”, “programmer”, “coder”, and “engineer” interchangeably. In all cases, I’m talking about someone who knows how to turn ideas into code that solves real problems. Some people make very fine grained distinctions between these titles. The people I find investing significant energy in these kinds distinctions always happen, by random chance I’m sure, to be on the high side of the chasm they’re insisting exists.
Intro made — let’s walk through the broad strokes of the technical career progression. Each of these descriptions is meant to be an entry point into the conversation about the level. You can follow the links in each section below to a more detailed description of the levels.
The junior developer level is all about learning things in order to immediately apply them to real work. It’s a very exciting level because every day contains both mysteries and answers to those mysteries. It’s all about overcoming the relentless confusion of what these tools are and how they work. What this “internet” thing is. How this server works. How that CI pipeline works. The junior developer is constantly discovering connections between things that blow her mind.
As a junior developer, she’s living in a world where some people around her definitely know the answers to her questions all of the time (or at least they ought to…). The junior developer is often making a tradeoff between how much confusion she’s feeling and how much she’s costing the more senior people around her by bothering them for explanations. As you might guess, this means that her experience of being a junior is in many ways dictated by how supportive her team is toward her. Good, nurturing tech leads and patient mid-levels can make the junior’s experience really exciting and challenging. The junior engineer is likely looking to these folks daily or roughly every other day for help.
Exiting the junior developer level means finding some foundation within the chaos. It means learning enough of the practical art of software engineering so that, mostly, she knows what to do when she sees a problem to solve. When the junior coder starts to know instinctively how to solve most of her day-to-day work without diving headfirst into documentation and Stack Overflow, she’s probably trending toward mid-level. By contrast, if she’s still mucking about in MDN, W3Schools, and copy-pasting stuff to see what works, she’s certainly still a junior developer.
Where the junior developer level is all about learning, the mid-level is all about learning how to harness all those new skills efficiently. The junior dev learnt to write good code fast. The mid-level dev now has to learn what code to write. What problems to solve. The mid-level developer is a bit like a kid in a candy store. Suddenly, she has all these new problem solving abilities. Suddenly that random error isn’t so random — it’s something that can be debugged. That mysterious issue with Git that required her to dump all her changes and reclone the repository isn’t so mysterious now. She can fix her repo and get back to work. Her productivity is way up compared to her junior-level self. Most of the time she’s just motoring through work, occasionally hitting some place where she’s not sure what to do. She might need support from a senior engineer every few days, maybe once per week.
The mid-level engineer is still in search of answers, much like the junior. However, the mid-level dev is looking for “why” answers where the junior is still working on “how” questions. The mid-level wonders why the backend uses a particular object schema within the REST API. She wonders why the code for this key piece of infrastructure is so old and broken down, yet no one has fixed it. She wonders how she could refactor this UI library to be more elegant, since the current implementation is hacky and brittle.
It’s exactly this newfound ability that makes the mid-level challenging. The mid-level dev can now handle abstractions and complexities that were inaccessible before. Now she has the higher-order problem of needing to decide what work to do. At the mid-level, it’s not uncommon at all to see engineers diving deeply into some interesting problem without thorough consideration about whether or not that work is actually worth doing. The discernment between “Ooh, this is fascinating!” and “Ooh, this is fascinating and let’s never do it,” is a key example of the difference between mid-level and senior. Bridging the gap between mid-level and senior is largely about sharpening that judgment. It’s also about learning how to find answers to key questions. Where the mid-level engineer often comes with tough questions that demand answering, the senior engineer will often already know the answers. And when she doesn’t, she rolls up her sleeves and finds them.
Update: It was pointed out to me by a very successful engineering director that my writeup carries forward a certain bias of tech companies. That is, we push people hard to attain technical seniority and then spring on them the challenge that they’ll also need “people skills” (whatever those wacky things are!) to become senior. I think this criticism is absolutely fair and the bias is absolutely present. As a mid-level developer, you may be under-developing your tech lead skills. You might find that your lack of such skills are blocking you from proceeding to seniority, even if no one is telling you so.
Once an engineer has acquired significant technical abilities, mastery of her tools, and enough people skills to facilitate a small team of engineers, she’s likely crossed into the domain of seniority. Seniority as an engineer is a very mixed landscape. What’s “senior” at one company is not “senior” at another company. If you talk with an advertising agency about what their senior coders are capable of, you’ll find they have a different set of expectations than, say, Google. What I’m describing in this post is technical seniority. Closer to what FAANG-esque companies would think of as “senior” or “tech lead”. My definition of senior would be insufficient in, say, a hybrid project management/software consultancy where client management and presentation skills are prized. However, this definition of senior does cover the most critical quality: To be senior, you need very good technical intuition and even better judgment.
It may surprise some readers that many senior engineers are no more skilled in terms of raw coding ability than their mid-level counterparts. It’s true though. Once she’s made it to the upper regions of the mid-level (on a decent team, with code review), she’s probably about as good at writing code as she’ll ever be. As a senior engineer, she can continue honing her coding skills. Especially with respect to managing higher complexity code and higher complexity codebases. There are many way to deepen her skills in terms of raw coding ability. It boils down to what sort of senior engineer she is. In the expansion post, we’ll talk about different types of senior engineer and what makes them who they are.
The senior engineer learns a new dimension of skills. She’s faced with hard constraints, like timeframes for delivering work that don’t allow everything to happen. She has to murder some darlings. She’s faced with a panoply of things she and her team could do. She has to decide what work actually needs to get done. She satisfices rather than indulging. She chooses pragmatic solutions rather than elegant ones. Most of these skills are learned the hard way. She learns mentorship skills because now she has to mentor. She learns behavioural interviewing skills because now she has to hire.
A mid-level engineer is likely to build elaborate castles in the sand — nifty and whizbang abstractions to solve small, often irrelevant, problems. She obsesses about particular implementation details trying to optimise them away or achieve the unachievable. After a year or two of this, the mid-level engineer wearies of her toils. She looks back at the hundreds of commits. At the brilliant microframework she created which no one is using. At the hours she spent trying to find an elegant solution to a completely intractable problem. “No,” she says, “No more.”
When an engineer turns toward senior, she grows a specific kind of incisive judgment. She’s well past being technically competent enough to understand the topics being discussed. Instead, she’s listening for time being wasted. For holes in the collective understanding of a problem. For senior engineers, it’s no longer about the naive joy of doing technical things. She has her sights set on delivering real work. She’s the pillar of her team not because of the work she does but because of how thoughtfully she spends her energy.
I hope this is a helpful discussion of the different engineering levels. I haven’t found many other write ups online that discuss these points meaningfully. As an “All ‘Rounder” senior engineer turned manager, it means a lot to me to be able to help other people grow in their career. This writeup is an attempt to take away some of the mystery about what separates the juniors from the mid-levels from the senior folks.
If you enjoyed this writeup, I’d love to hear from you. If you hated it, I’m all ears, too. If you have questions or you want more details, please just ask. I’m happy to expand on any topic here.