Defining roles is tricky.
After all, assigning a junior/regular/senior level to somebody is a bit like trying to compose the entirety of their skills in a single ‘label’.
I’m interviewing quite a lot of folks for frontend engineering roles at OLX Group and one of the questions I quite often ask (spoiler alert!) is:
”In your opinion, what is a difference between a senior and a regular developer?”
Note: I’m not a fan of the ‘regular’ developer label, maybe I should use mid-level but that’s also weird so let me stick with ‘regular’.
There is no right answer to this question. And I don’t expect every answer to be the same. Personally, I consider it to be an invitation to talk about the broader scope of what we do as developers.
I also honestly want to learn other perspectives.
Is it our job to just write code? Or is it writing tests? Or shipping to prod? Mentoring others? Writing documentation? Are we human? 🎵Or are we dancer?🎵
When I started my career as a developer I remember being incredibly impressed by senior engineers in the company I worked for. They seemed indestructible to me, I felt you could throw any problem at them and they would solve it.
And yes, as a senior developer you should be able to solve a wide range of problems related to your field of expertise.
But seniors are not machines.
Nor should they be - seniority is not a matter of ”this person can implement 30 redux actions per hour”. I’m sure there are companies where being a better, faster, bug-free (lol) developer will get you promoted but I honestly believe that there’s so much more to this whole Seniority thing. It’s not the “what?”, it’s the “how?” and more important - “why”? that matters.
There are entire books written on making technical decisions. It’s an incredibly complicated field and there are multiple factors to consider. The best approach is having multiple options so there’s something to reject. Instead of usual:
“I’ve been doing it this way for the last 20 years so we’ll continue doing that because I don’t know anything else and I’m frankly a bit scared to learn anything new”.
All of that is incredibly important, but here’s the thing.
What I do believe is that senior developers are meant to have an impact on their organisation. Which means - it’s not only about translating JIRA to code anymore.
Thinking outside of VSCode box
Allow me to quote someone really smart to kickstart this section:
Your goal is to solve problems with code.
If you have a deep understanding of the system you’re building/maintaining then you can make decisions outside of pure tech. Is this feature even necessary? What problem does it solve? Can we solve this problem any other way? Do we want to solve this problem in the first place?
This line of thinking is sometimes referred to as business context, but if you want to do your job well, you should not only understand the context, but to be able to shape and influence that. You don’t have to have a C-level position in your organisation to influence your product. Or at least - to understand it.
It’s not only about the code that you do write. The code that you don’t end up writing can be equally as important. Senior developers are able to think outside of the code layer, to look at their product from a wider perspective and consider whether their next line of code will contribute to team’s goals.
To give you an example:
You could spend a sprint implementing two different versions of a certain piece of the UI with redux-helicopter according to the spec and then enable an A/B test to verify that. That’s a great approach.
Although you may consider that (for example) 20% of your users are responsible for 80% of your sales. Why not send them an email? Ask them about their opinion? Or straight up call them?
Of course, this is just a silly example but it illustrates a point - thinking problem-first rather than code-first. Most problems can be solved in multiple ways and senior engineers are able to think outside of the Visual Studio box.
Being there for others
You know the feeling how you know exactly what the feature is all about so you can put on your headphones and code the day away? It’s awesome, isn’t it?
It is - unless you consider that folks around you may be less certain of their work. Seniors are meant to guide other, less-experienced devs along their journey. I’ve personally met too many devs with quite a lot of experience who clearly forgotten what it was like when things were incredibly confusing all the time.
What’s important to remember here is that not everyone is suited for 1on1 face-to-face mentoring and that’s okay. You can have others achieve their goals by meaningful code reviews, making sure that READMEs make sense, contributing to documentation and architecture decisions (which, ideally, should be well documented). In short, by being a +10% engineer
Seniors have a lot of experience and it’s absolutely unfair to keep it all for themselves. What I do personally consider to be a decent chunk of that position is facilitating a knowledge sharing culture.
Blogging, presentations, documentation, pasting links on Slack - you name it. It’s tragic to see two different teams in the same company solving the same problems twice - senior devs are meant to ensure that it doesn’t happen.
Sounds neat, how do I get promoted to a senior role?
Start by promoting yourself first.
Seriously, the best way to get promoted to a senior role is doing the work before you’re officially a senior.
Embrace a wider perspective of your code and how it’s related to the entire system. Get involved in monitoring, maybe there are some opportunities for optimization? Run a performance audit of your app (before someone tells you to), make an impact by cutting your homepage by 10%. Start helping others (they’ll appreciate that). Either kickstart a knowledge sharing culture in your organization or become an active contributor to those initiatives. Volunteer for projects and tasks outside of your comfort zone.
And best of all - good luck!
...
This piece was originally published by Tomasz Lakomy. You can find the original piece here.
