How I Went from Student to Senior in 3 Years (Part I)
There are no shortcuts to take and no preferential treatments to benefit from, but some people will suspect you of both once you start doing these things.
Reaching the senior software engineer title is something many of us pursue and strive to achieve. When I started my career in 2016, this seemed like the sun behind the sea — something to admire, but a million miles away.
I asked all my senior teammates how they did it, how much it took them, and how they felt. Interestingly enough, I kept getting the same standard answer that it’s just a title and that it will come with experience.
I get it. We try to stay humble as much as possible. We try not to brag and that’s totally fine. But I still wasn’t receiving my answer and for me, it’s more than a title. So here is what I would have loved to hear when I started and at many moments along the way.
First Offer, Than Receive
One of the fundamental questions I’ve asked myself and my manager is what value do I provide and whether it’s enough to even cover my salary. At one moment, I was strongly considering demanding a smaller paycheck because I felt like the results of my work were not generating enough value.
It turns out I was just taking for granted and even forgetting certain parts of my work. Luckily, not everyone did that. During the yearly performance review, my manager highlighted several activities that brought real value even though it was pretty hard to quantify exactly how much.
Besides fulfilling my job description as a programmer (you know, implement stuff, complain about legacy code, chug gallons of coffee), I also helped with internship programs, mentoring new colleagues, presenting at events or customers, and providing technical feedback for others. This is how I have been celebrating the 30th of November, my name day, each year since I started my career — by putting together all the feedback I had for my teammates.
I’ve been doing all these not because someone asked me to, but because I felt it was my duty. It turns out not many people feel the same. Providing value without asking for something in return will be like driving a supercar while everyone else is waiting in line at the train station.
Of course, I am not saying to work for free or to let people take advantage of you. If you want to do quality work, you need to (easily) cover your and your family’s basic needs. In an ideal environment, this is a non-issue. However, things are never perfect and we might find ourselves having cynical thoughts.
Cynicism
While a certain dose of cynicism is healthy, just as with anything, including washing our hands, too much is detrimental. Being cynical simply doesn’t work when it comes to growth. It usually goes against innovation — and I really mean it since I am using such a buzzword.
If you believe your employer simply wants to take advantage of you and turn your time and energy into money for themselves, you will become just that. You will always think in terms of what’s in for you and how the employer is ripping you off.
Now, if you find yourself in this situation, there could be good reasons. If the cynicism comes from the culture (or rather the lack of it) of the organization you are part of, you might be playing the wrong game or at least at the wrong table. However, if it comes from your lack of faith in humankind in general, trying to set your priorities in life will help.
The true cost of cynicism is opportunity cost. Your RAS (reticular activating system) will focus on tipping the scale in your favor rather than building value. Because of this, you will never go the extra mile to overdeliver.
Overdelivering
When we are promoted it’s not because we dream big or because we are friendly and nice persons. While they are important factors, the decision is mainly based on our results.
Delivering more than you are expected to creates a mismatch between your current position and your actions. Moreover, it gives people confidence in you. This, in most cases especially at the beginning, leads to you being promoted.
One important mention here is to overdeliver on things that matter. While always creating pristine PowerPoint slides and drawing perfect circles is great, they don’t provide that much value. One way to have a greater impact on your project is to stay ahead.
Staying Ahead
Most of us are following some sort of SCRUM methodology. This means that we probably have a backlog and a product owner. Both of them are lonely. We are constantly focusing on implementing the features in the current sprint while relying on the product owner to steer the ship.
Glancing through the next stories from the backlog (should be the ones from the top) literally takes a few minutes and will earn you the appreciation of the product owner for life. The ROI on this is astounding, not to mention that literally, nobody does this.
During the next refinement, you will be able to actually contribute to the discussion because, again, your RAS will focus on the things that matter rather than understanding the story.
You will be able to bring in your expertise and provide a proper estimation based on what the product can do now. Not only this, but you will also consider future stories in your current implementation. This translates into meaningful abstraction layers in your code. Another way to write better code is through side projects.
Side Projects
This one is actually hard because it requires either discipline, passion, or ideally both. No one is paying you for your side projects (at least yet; if you’ve managed to build a SaaS product, please brag about it).
I’ve been working on various applications ever since I started my career and literally each one of them helped me do my job better. From developing a better sense for prioritization and critical thinking to actually giving you an “unfair” advantage when it comes to the actual systems that you build at work.
Some examples include building web apps with Vue, using NoSQL databases such as Firestore and DynamoDB, building on FaaS services (Lambda, Google Cloud Functions), using Stripe to handle payments and even build full-fledged marketplaces, and implementing product search using Elasticsearch.
In most cases, just a few months after using these technologies on my own, new projects emerged being built on them. Moreover, you will be able to contribute when choosing the tech stack based on what you’ve learned. Maybe no one in your team knows any frontend framework and you noticed that Vue’s learning curve isn’t too steep.
Ending Notes
These are roughly half of the approaches that worked for me and chances are they will work for you too. There are no shortcuts to take and no preferential treatments to benefit from even though some people will suspect you of both once you start doing these things.
