According to this research, to become a senior software engineer you need 5-10 years of experience. Seems straightforward - you stick around for long enough, you get the title. Eventually. ⏳

But if you want to become a true senior engineer and you're willing to put in the time and effort, you can do it faster. So what can you do to jump to a senior position in, let's say, 3 years instead?

The skills that will get you there might not be what you expect. Here's a subjective list of five lessons that helped me on the path to senior software engineer. 📋

Own the process

Ownership is probably the single most important aspect. As a senior engineer, you should be able to handle the entire software development cycle end-to-end.

You should be involved in the problem analysis. You ask for business context. You should challenge the existing idea to see if there's a better or a simpler way to achieve the same result. You map business requirements to actionable tasks. You make sure that business understands the complexity and potential duration of the project. You are responsible for architecting the feature and deciding on implementation details. You check for dependencies. You report on the progress and blockers. You plan how to roll the feature out safely and monitor it on production. When there's a bug, you make sure it's fixed.

You might ask, but wait - shouldn't at least a part of all of that be handled by a manager or a product owner? Well, technically yes, but they only see half of the entire picture. It's you who have the technical context and it's in your best interest to get it out there as soon as possible. Otherwise, you risk that halfway through the project it turns out that a critical part cannot be implemented due to a technical decision you've made at the very start simply because you didn't have the full context. Crap. 💩

And also, try to think like a business person - you've got an idea or a feature you believe will give value to the users. With what kind of engineer would you like to work with? The one who listens to you politely then disappears for 3 weeks and shows you something that only partially solves the problem? Or the one you ask a lot of relevant questions, proposes a simpler solution that can be implemented in half the time, gives you periodic demos allowing you to improve the initial idea, and architects the solution in a way that it can be gradually rolled out to clients even though you didn't ask? 🤩

That's why ownership and responsibility are so important.

Be a force multiplier

This is a lesson learned from Swizec Teller and his Senior Mindset Series.

In military science, force multiplication or a force multiplier refers to a factor or a combination of factors that gives personnel the ability to accomplish greater things than without it.

What does it mean exactly for you? Can you quickly dig into a problem that someone on your team has or explain a part of your codebase saving them hours of going through the code? Can you resolve this one bottleneck in your build process making it effectively 20% faster and saving literally hours for every other developer?

That way you make your time ten times as valuable. Pretty good, right? 💪

Does this mean you will code less? Absolutely! But remember, your point is not to code as much as your time allows. It's to make a project successful for your team. You can often get more out of your time by helping others, sharing knowledge, and looking for meaningful improvements.

Have your technical skills on point

There's no escaping, that at a certain level of seniority you need to have solid skills and experience. Here are a few areas I recommend paying attention to.

1. Know your tools in and out. The ones you use daily for your work - your programming language of choice or a framework. Every investment in fundamentals or better efficiency will have huge returns since you interact with these tools so often.
2. Pay attention to design, not only implementation. Code changes all the time. But all changes have different costs - implementation is often relatively easy to change, but overarching abstractions or software design - not necessarily. So make sure you make the best decisions for the latter group - familiarize yourself with design patterns and think about how your code might scale and evolve.
3. Explain and give reasoning. If you think you understand something, try teaching it to someone. You might realize how much you're missing. At this level, it's essential you not only understand things but also can explain them and clearly communicate reasoning for your choices.

One last important thing to mention is you don't have to know everything. First, it's impossible - there are just too many things you could learn. Second, it's highly ineffective, as you'd probably never use the majority of the things you could learn. What you should be great at though, is being able to learn fast - know how to use online resources and effectively read the documentation. This will allow you to adapt to any situation in the future, which leads nicely to the next point.

Adapt to the situation

Let me tell you something. You won't find a junior position on my resume. It's not because I don't want my future employer to know about it, but I was never employed as one. 🤷

When I first wanted to get a job, there were very few open positions for a junior where I live. I was still studying at that time, so I could only work part-time. This limited the options for me almost to zero. So I decided to use this time differently.

1. I spent a lot of time learning and building side projects with my student club. Joining learning-focused communities is a great way to improve very fast.
2. After a while, I had enough experience to find clients directly in my area. I worked with them on basic web design and web development. All of that gave me a good grasp of front-end development fundamentals and a track record of successful projects.
3. After a little over a year of doing that I applied straight for regular engineer and had no difficulty landing a job.

The point here is that you don't always have to adhere to the structure. There are many alternative ways to gain the experience you need.

Your career path is just one example. Remember, it applies to any roadblock you face. Be persistent. Adapt to the situation you're thrown into. Hack your way through.

Give feedback and ask for feedback

It's hard to know exactly where you are if you don't measure your progress. Setting goals for yourself and tracking them is important, but asking for feedback is equally as important. At last, a lot depends on how people perceive your work - that's just the reality.

Many companies have the standard one-year review during which you receive some feedback from your manager. That's great, but sometimes you just need more. More details on the technical skills. Or more information on how you perform as a team member. It never occurred to me that but... I can also get feedback on my own. I just had to ask.

I did that with a couple of my colleagues some time ago and was blown away. I got surprisingly detailed responses, both on the technical level as well as on the personal level. The key takeaway though was that in other people's perception I was actually much closer to senior level than I would have ever thought. And I would have never known had I not asked for feedback directly.

Finally, be first to return that favor if you have a chance. When you see someone doing something good, make sure you recognize that. If you see a poor solution, point it out, explain why you think so and what might be a better approach. That's how you help others grow. 🌱

Conclusion

These five lessons helped me the most on my way to senior engineer. Here's a quick summary.

1. Own the process. Handle the entire development cycle from the beginning to the very end.
2. Be a force multiplier. Help others, share knowledge, and look for improvements that elevate your work.
3. Have your technical skills on point. Learn your tools inside-out, provide reasoning behind your decisions, and know how to learn fast.
4. Adapt to the situation. Look for solutions to problems, even in unexpected places.
5. Give feedback and ask for feedback. Learn where you stand in your knowledge and experience, and help others grow.

The path to senior took me a little over three years of working in the industry. What allowed me to get there that fast was more about the mindset shift than technical skills. 🧠

One last thing. Senior engineers do not exist in a vacuum. Make sure you are a person that others simply like to work with. Be kind. Be helpful. That helps immensely.

I hope some of these lessons will also help you on your path to senior software engineer. Good luck!

Further reading and resources

• Photo by Francisco Gonzalez on Unsplash