In the world of software, just because someone has been a developer for a long time, it doesn’t mean they have become excellent at it. In my experience, what differentiates senior developers and engineers from junior and mid-level ones is how they use skillsets and approach problems. While this varies among types of organizations — the skills used by a senior developer in a small startup aren’t the same as those used by one in a massive company — there are a few clear qualities that all experienced software folks with a “senior” title have.

The idea that we can categorize developers and engineers into junior vs. mid-level vs. senior suggests there is some way to measure. The mistake here is pretending there is a single scale of measuring talent when there isn’t. Different organizations, problem sets, and domains suggest very different skills. But there are four key abilities to use in measuring seniority:

Ideally, a senior engineer should be strong at all four of these skillsets, but it’s more critical that their strengths complement the team and company and their needs. So the relative importance of these four skills can vary widely. For example, in a small company or startup, skill as a sole programmer and the ability to grow other programmers typically matters far more than social and political skills.

It’s not that startups don’t have those issues, but they are far more compressed than a large organization with extensive teams with several managers and different goals and KPIs (key performance indicators). At a large company, a senior developer’s political and social skills may matter more because they may need to be able to defend technical choices to non-technical staff far more often.

More Than Just Knowledge

Software is a highly technical field, so a senior engineer obviously can’t be weak in knowing a lot about how things work. But anyone at a senior level is expected to be what I call a “specialized generalist”; they should have been doing development long enough that they’ve seen a wide variety of issues. They have likely gotten deep exposure to the problems of a specific field or industry, which is important because understanding the details of multiple domains can help the developer transition to other areas with more than just a broad surface knowledge.

To truly be senior, you need to make the hard calls and make them right.

This deep experience also builds the wisdom to see how choices made early in development pay off later. A senior developer needs to know “where the bodies are buried.” Time spent in the deep end lends itself to an intuitive knowledge of where problems will occur 10 steps down the line. And this wisdom is surprisingly transferable to other situations; at a minimum, senior developers are able to realize when they don’t know all the secret potential dangers and act with caution.

This intuition, more than just writing code really fast, is what pays off for companies. Good choices by a true senior developer mean that problems don’t happen.

Making Tough Calls and Living with Them

This is the real secret: There are no magic solutions to all software problems. There’s almost never a time where a decision is made and everyone packs up, goes home, and never touches it again. Every architecture, every choice, every possibility carries possible downsides, especially as products expand and evolve.

The choice you make today to ship quickly to beat competitors to market may mean that you need a major refactor in six months rather than in six years. But if that means you win market share and revenue, it might be worth it.

To truly be senior, you need to make the hard calls and make them right. When you choose a solution, you also choose the problems and issues the team will live with. A senior developer will have had exposure to multiple design paradigms, multiple languages, and multiple teams. And while it’s almost impossible to deeply know every possible design and architectural pattern, especially as things keep changing, it’s very possible to have a good awareness and understand the advantages and tradeoffs of different approaches.

Open-Mindedness and Plucking the Good

Some people may think owning decisions comes down to having strong, unmovable opinions. But I consider it a bad sign if a senior developer is too opinionated about technologies — if they think major languages are “junk” or get worked up too much about such things. A team may be called on to interface with a major product written in a language a senior developer doesn’t like, or there may be fantastic libraries with great support in that language that can solve a problem perfectly.

The more open to knowledge and understanding someone is, the more quickly they will become “senior” by any definition.

A good senior developer doesn’t have to love all languages and frameworks equally; in fact, it’s best to be somewhat dispassionate about it. These things are tools, and an experienced developer knows when things have been done a certain way for a reason. Instead of worrying which ones are worse or better, a true senior developer will pick the right one for the problem, their team, and their company and realize the rest is noise.

A perfect example is PHP. A lot of developers love to hate on PHP, but many of its flaws were also what allowed it to conquer the web. We shouldn’t laugh; we should think how we can take the good things from it and avoid the bad going forward.

“Senior” Qualities Will Emerge

Considering some of these qualities and factors of measuring, junior vs. mid-level vs. senior can be broken down generally like this:

  • Junior developers know one way to solve a problem, usually based on tutorials or something they did in school. It’s almost certainly using some trendy framework.
  • Mid-level developers understand that every problem exists as part of a larger system and worry about maintainability, code quality, and so on but still don’t see the big picture. They tend to get more hung up on the process.
  • Senior developers understand that nothing is without possible issues, downsides, and risks. Their choices are not about what’s cool or “correct” according to some book as much as they are about holistic risk management across the entire team. They care about what’s going to be easy to maintain, easy to teach, and easy to debug.

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 I’m in doubt about hiring someone as a senior developer or engineer, I ask if they are willing to own up to not knowing and find out how eager they are to at least see what might be possible. “Senior” qualities will show and help determine if the title is truly earned.

What are your experiences? When did you feel you were ready for the ‘senior’ mantle?