Estimated reading time: 6 minutes
If you're a junior engineer, making senior engineer has definitely crossed your mind.
Let's be honest:
There's a lot of benefits to being a senior engineer.
You get more decision making power, the pay is better (always a good thing), and you're able to mentor and train the next generation of software engineers.
But it can also be intimidating:
How do you actually become a senior engineer, other than having an arbitrary X years of experience under your belt?
What are some things you can control?
Today, I'm going to share 3 things you should do right now as a junior engineer to help you jumpstart your career and rise to the top as a senior.
The best and brightest engineers I worked with all specialized in a specific area of development.
Think about it:
As a senior engineer, your expectations are worlds apart from a junior engineer. Coding proficiency is a foregone conclusion, and that's not why organizations hire senior engineers.
They want you to apply your experience to difficult, cross-cutting problems.
Questions like scaling an application earning $100,000 a month but is running into a byzantine, complex bottleneck that's hindering growth.
How do you solve it? Is it a rearchitecture? A new service? It depends on the nature of the bottleneck. Can you find and identify the bottleneck? How do you rollout and execute?
This example is backend focused, but the idea is simple:
You can go deep into the rabbithole for every area of development.
And as a senior engineer, you're expected to be deep in the rabbithole.
Let's face it:
It's a lot easier to get deep, grounded experience when you focus and specialize on a single area.
There's a saying for the opposite:
If you chase two rabbits, you'll lose both.
If you're jumping between frontend and backend every other day, distracted by the next shiny thing, you'll never get that deep level of experience that makes you so valuable .
After all, there's got to be a reason why the pay is better.
The bottom line:
Companies hire senior engineers to tackle difficult problems. Manage your time and pick a niche.
This next tip here is as good as gold.
I'll never forget the day it was shared with me. It was like the heavens parted and a gigantic hand reached down from the clouds and smacked me in the face:
Have strong opinions about why things should be done a certain way.
This is only possible by niching down and becoming an expert in your field so your opinions are grounded in experience, facts, and data .
Otherwise, you'll have strong opinions backed up by sticks and twigs. People are really good at spotting B.S. and you will look like a fool.
Concretely, you should be able to defend every line of code you write during a code review.
Heck, I'm feeling generous today.
I'll give you a script you can respond with when someone says:
"I see you took approach X to solve this. It might be better to do it via approach Y which gives benefits a, b, and c".
Kind of intimidating, especially if it's from a senior engineer.
You can reply with a script like this:
"I considered approach Y but found it to have the drawback of introducing negative impacts to d, e, and f. For these reasons I decided on approach X."
Now this is great when you're right and you did your homework. But sometimes…
When you're wrong, you're wrong.
I really want to stress this. Nothing is worse than a teammate who has a deep conviction that their way is the One True Way, even in the face of hard facts and evidence.
It's really weird:
People seem to have an innate fear of being wrong.
I suspect this came from grade school where you raised your hands to answer the teacher's question. If you were wrong, it looked like you volunteered to look stupid.
This has sadly stuck with us into our adult lives.
Being wrong is actually a Good Thing for you, your team, and your company.
It means someone has thought of something you didn't think of. This means:
I'm feeling extra generous today, so here's another script to say when you're wrong:
Wow, good point. I hadn't thought about that. If that's the case, we'll need to adjust the design here…
And now you're off to the races.
No, I don't mean you're literally a junior engineer for life.
But think about it:
As a junior engineer, your attitude is, "there's a lot I don't know, so there's a lot to learn".
This is a great attitude to have, and even better to have as you continue your career.
Otherwise, your skills will rot and decay.
That's because engineers are people. And people are lazy.
And when you combine human nature with steady career progression and the attainment of a goal, you get comfortable.
You've attained senior engineer status. You've got great responsibility at your job, you're giving tremendous value back to your organization, and you're earning a great paycheck.
"We made it" says your brain. "Why work any harder? My skills got me to where I am today. Let's just chill".
And so the steady decline begins.
Java moved to 6 month release cadences a few years ago. Python 2.7 is finally getting EOL'ed in 2020 and 3.8 is coming out with a handful of new features like the walrus operator. The Go community (team?) is marching towards Go 2.
Here's a dirty little secret:
In software, you never really "make it" if you want to stay competitive in a cutthroat landscape .
The harsh truth:
A lot can change in 1 year. Even more can change in 3. And if you think your outdated skills from 3 years ago will innovate and win for your company, you're out of luck.
So get used to being a "junior engineer for life", and get used to learning something new everyday. You'll thank me later.
If you're a junior engineer, I hope these tips help you in your career as you progress towards a senior engineer title, or staff, principal, whatever.
And if you're more experienced, I hope this post scares you a bit. Otherwise that junior engineer will come and eat your lunch.
 I'm not saying to never, ever jump the gap from backend to frontend. At some point, you'll need to add breadth to your depth of knowledge. This is where company hackathons come into play.
If your company doesn't do hackathons, then pick a side-project and start hacking!
 This is partly why there's a "X years of experience" requirement in senior engineer postings. You can't really have opinions about anything until you've been doing it for awhile.
Obviously, 3 years at a start-up and 3 years at a large enterprise company look very different so it's not the most accurate measure, but that's a post for another day.
 As an individual contributor. A metaphor for this is like stepping on the gas when you drive. Once you reach your ideal speed of 50MPH, you don't take your foot off the gas. You keep it there.back