How to go from Junior to Senior Software Engineer — the faster way
During one on ones with more junior engineers I often get questions like “what should I do to get to the next level” or “what should I improve on” or even “what defines a senior engineer” and although there are multiple answers for all of these questions, there are some generic parts worth talking about.
But first, keep in mind there’s no standard about what “Senior” means. Different companies have different definitions for it and there might also be a big delta between the title and the skill set. It’s not uncommon, specially in the startup world, for higher titles to be given as a hacky way to prevent people from leaving. It’s also not uncommon for big companies to down-level people when they join so they have more room for promotions.
I’m not here to talk about how to get promoted though. I’m a big believer that you should focus on increasing the value of what you produce and that the recognition will follow, assuming you’re not in a dysfunctional company (if you are, scroll to the end of this article).
So, technically, how do you improve faster?
1. Try to understand how everything works under the hood (extreme growth mindset)
As engineers we often face problems that we don’t know how to solve and we’re expected to figure it. Some problems turn out to be trivial, being solved with a simple StackOverflow search, but the harder ones will take days out of your life.
The more you know about how things work, the easier it will be to spot things that are misbehaving and spotting what is misbehaving in a complex system is usually half the work for fixing it.
If you don’t know how things are supposed to work, you’ll waste a lot of time and that will impact your output. As you know as a senior engineer, you’re expected to have a high output, constantly.
This means you should slowly try to understand more about everything supporting your work. Nobody has the time to sit down and deeply understand everything, but you can try to learn a bit more every time you interact with something you don’t fully know. Do this and it’ll pay dividends in the future.
For example, let’s say you’re working on the backend side of an app, with a frontend team sending you the requests and and a devops team handling your infrastructure. So you get your requests, you grab data, you do your magic and you respond and that’s all you need to do your job. However, if you understand:
- What the frontend is trying to do, you might suggest creating a new endpoint that simplifies their code and improves the UX.
- What the infrastructure is doing, you might notice that the network latency in some of your requests is an order of magnitude higher than it’s supposed to be, uncovering that your storage is in the wrong availability zone.
- What the user is trying to do, you can suggest product changes that might improve the conversion rates of your app
- How the database is performing it’s joins, you add an index to speed things up
- Where your costs are, maybe you’ll realize you’re getting virtual machines that are too much for what you need and you can downgrade, saving your startup money
Foster your curiosity and feed it from time to time.
2. Optimize for lower maintenance costs
Maintenance costs suck and you should do everything you can to reduce it. They spend a huge amount of time and move the company forward exactly zero inches. Here you have things like:
- Fixing bugs the right way if they happen more often than not.
- Write simpler software. Make KISS your mantra. Simple things are easy for anyone to read, to fix and to add to. Complex things produce more bugs, can be maintained by fewer people and slow the team down. Even if it takes more time to make things simpler, that usually pays off big time.
- Only add tech debt intentionally if the trade-off makes sense at the time, but make sure to clean it up or throw it away later. Business people always pick the quick and dirty approach if given the option. Try to understand what they’re trying to achieve and negotiate more time if you think it’s not going to hurt them. It’s your job to protect your team’s future output.
- If you have to make a kludge because of a timeframe, make it contained and easy to remove later.
- Good tests prevent bugs and the cleanups that they require. Learn to write good tests and take care of them. If you have flaky tests that are always a false positive, either fix them or delete them. If they’re important, write them again from scratch.
3. Know when to ask for help
Don’t allow yourself to get stuck. If you find a problem and after really trying if you’re hitting a wall, ask for help.
When that happens and someone is helping you, make sure to pay full attention and to understand everything that’s going on.
The most important part to learn isn’t the solution, but how the other person figured out the problem. If you learn that, you can do that yourself next time and you’ll be one step more senior than you were before!