What makes a senior developer?
It's not your age, in case you're wondering...
How do you know the moment you turn from a Jr. developer into a Sr. developer? I wondered that same question for the longest time. It definitely can’t be time on the role nor age, those aren’t factors that translate directly to the quality of the delivery.
How can you tell then? After a lot of observation, I was able to come up with my own list of characteristics, based on what I was seeing my Sr. colleagues do that I wasn’t able to. And lo and behold, once I started working on them, trying to imitate or work with those in mind, I was promoted to Sr. developer.
After that, and throughout the rest of my years, I’ve been able to find the same characteristics that make up a Sr. developer on the teams I’ve led.
And here they are:
Autonomy
Sr. developers can work with minimum direction from their leads, this is because they’re able to apply past experiences to their current tasks.
They’ve been around enough so they know when it’s OK to make a decision for themselves, and when it’s better to ask for guidance.
Don’t get me wrong, a Sr. dev is not someone who goes off and does whatever they want. Quite the opposite, and the moment they hit a roadblock, they’ll know to ask for help before spending too much time trying to solve something someone else has already solved.
Decision making
Deciding on how to solve a problem, who to contact when a problem is found, refactoring a piece of old code that’s been pending for a while. These are all decisions that normally a Sr. developer is able to make on their own because they’ve done it before. They know the implications of that refactoring and they probably have a pretty good idea of how long it’ll take them.
Being able to make decisions that influence the project, even on a small scale, and being able to own them (and their consequences) is a very clear characteristic of a Sr developer, one that is likely to be considered a leader soon.
Lasting contributions
Sr. devs are the ones who tend to develop the tooling and frameworks that the rest of the team, including the Jr. devs use on their everyday tasks.
This is not a rule, of course, but I’ve seen it happen so many times that I tend to see it as a sign of seniority. If you’re building code that covers your team’s use cases so well, that they’re promoted to official tooling, then it’s a sign that you’re doing things right.
It means you understand the work you and your team do so much, that you’re able to simplify it. This, in turn, saves time and removes the chance for human error when doing manual things.
Business in mind
Sr. devs keep the business in mind. This is not about forgetting or minimizing the code writing portion of their day. Instead, it’s about focusing that portion to serve a business purpose.
If you only care about the task you’re given, without second-guessing it or questioning why you’re doing it, you’re not adding a lot of value, you’re just fulfilling your task. Mind you, it’s an important task, but if at the same time, you can question and analyze the value your work brings to the project, then you’re potentially catching issues, helping re-set priorities, and adapt user stories.
That’s the value a Sr. developer brings to the business.
Are you a Sr. developer? Do you qualify using the above criteria? Or maybe you disagree with me?
Are you still a Jr. dev but you feel like you’re already fulfilling these actions? Send me an email at fernando.doglio@gmail.com, reach out, I’d love to help!
By the way, this is part of my weekly newsletter on Substack, if you haven't joined yet, consider taking a look .