One of the things I’ve noticed in my career in software is that just because people have been a developer for a long time, that doesn’t mean they have gotten excellent at it. I’m going to talk about my observations about senior developers and engineers, and what “senior” should mean, because age truly isn’t a number. How do you even measure? Even bringing up the idea of junior vs senior vs mid-level engineering suggests that there must be some way to measure. The mistake here is that we pretend there is a single scale when there isn’t. Different organizations, problem sets, and domains suggest very different skills. A senior developer in a small startup needs different skills than a senior developer in a massive company. To that end, any discussion of “senior” needs to look at a set of 4 skills: Ability as a sole programmer Ability to mentor and grow other programmers Ability to navigate social and political issues inside an organization Ability to match technical solutions to business needs. The relative importance of those 4 skills varies widely. In a small company or startup the skill as a sole programmer and the ability to grow other programmers matters far (typically) than social and political skills. This isn’t to say that startups don’t have those issues, but they are far more compressed than a developer trying to work with large teams in different buildings with different managers and different goals and KPIs that might indicate a large organization. Similarly, at a large company the political and social skills of a senior developer may matter more than their technical skills, as they may need to be able to defend technical choices to non-technical staff far more often. Ideally, a senior engineer should be “strong” at all four of these skillsets, but more critical is that their strengths complement the team, the company, and their needs. The Technical Stuff Software is a very technical field, so obviously a senior engineer can’t be weak here. At the senior level, you should expect what I call a “specialized generalist”. A senior engineer should have been doing development long enough that they’ve seen a wide variety of issues. In doing so, they have likely gotten deep exposure to the problems of a specific field or industry. This is actually really important. Doing a deep dive and really understanding the problems of a specific domain deeply helps the developer transition to other fields more than just a broad surface knowledge. Why do they need such deep experience? Because it builds the wisdom to see how choices made early in development pay off later. They need to know “where the bodies are burried”. Enough time spent in the deep end will lend itself to an intuitive knowledge of where problems will occur 10 steps down the line. And this wisdom is surprisingly transferrable even to other specialities. At minimum, they will be able to realize when they DON’T know the secret dangers, and act with appropriate caution. And it’s this intuition more than just writing code really fast that pays off for companies. It’s the hidden secret sauce, because good choices by a senior developer mean that problems don’t happen. They don’t need to be heroic because there was never a big problem to begin with. They choose the problems they are willing to live with (for now) This is the real secret. There are no magic solutions to all problems. Every architecture, every choice, every possibility carries possible downsides. This is especially true as products expand and evolve over time. The choice that you make today to ship quickly to beat competitors to market means that you may need a major refactor in 6 months rather than in 6 years. But, if that means you win market share and revenue it is probably worth it. That’s the key skill. To truly be senior you need to make the hard calls and make them right. Whenever you choose a solution, you also choose the problems and issues the team gets to live with. With large and ongoing development projects, there’s never a solution where everyone gets to pack up, go home, and never touch things again. Customers always want more, and you’ll always be asked to deliver. A senior dev should have had exposure to multiple design paradigms, multiple languages, multiple teams. It’s almost impossible to deeply know every possible design and architectural pattern, especially as things keep changing. But it’s very possible to have a good awareness and understand the advantages and tradeoffs of different approaches. My Technical Hierarchy Here’s how I break down skill by junior/mid/senior level: Junior devs only know one way to solve a problem, usually based off of tutorials or something they did in school. It’s almost certainly using some trendy framework. Mid-level devs understand that every problem only exists as part of a larger system, and starts worrying about maintainability, code quality, and so on, but still doesn’t see the whole forest. They tend to get more hung up on process like “Are we doing agile right”. Senior devs understand that nothing is without possible issues, downsides, and risks. Their choices are not about what’s cool, or what’s “correct” according to some book as much as they are about wholistic risk management across the entire team. They don’t care about what’s trendy, they care about what’s gonna be easy to maintain, easy to teach, and easy to debug. Put another way, many junior devs are interested in going as fast as possible RIGHT NOW. Senior devs are more concerned wit making sure every step forward isn’t going to trip them later and at the worst possible moment. A bit of contrarian thinking Unlike some others, I consider it a bad sign if a senior dev is too opinionated about technologies. If they think major languages are “junk” or get worked up too much about such things. The truth is a team may be called on to interface with a major product written in that language or there may be fantastic libraries with great support in that language that solve a problem perfectly. You don’t have to love all languages and frameworks equally, but experience usually tells you that things were done for a reason. In fact, it’s best to be somewhat dispassionate about it all. These things are tools. Instead of worrying which are worse/better, a top senior dev will just pick the right one for the problem, their team, and their company. The rest is noise. A perfect example is PHP. A lot of developers love to hate on PHP, but many of it’s flaws were also what allowed it to conquer the web. We shouldn’t laugh, we should learn and think how we can take the good things and avoid the bad. Best bet: Humility and Eagerness to Grow Senior or otherwise, an engineer who accepts that they don’t — can’t, know everything is the best choice. The more open to knowledge and understanding someone is, the more quickly they will become “senior” by any definition. Whenever in doubt about someone when I’m looking to hire, I ask questions to see if they are willing to own up to not knowing, and how eager they are to at least see what might be possible.
