Five tips for becoming a senior software engineer

Zone
6 min readJan 28, 2021

--

Zone senior full-stack developer Jacob Pretorius offers his advice to ambitious developers looking to take the next step in their careers

As an active mentor on codingcoach.io I hear from lots of ambitious developers who want to advance their careers. It can be difficult to say what makes someone a senior and when they’re ‘there’, so I’ve gathered my top five suggestions on how to set yourself up for success.

1 — Take ownership

The number one most important thing that sets seniors apart is that they take ownership and are able to work (at least somewhat) autonomously.

As a junior it’s perfectly fine and expected that you may sometimes need to work more closely with others on issues and projects. This is totally natural and, as you see your skills and experience grow, you’ll find yourself being able to work more on your own, only needing to occasionally touch base with others.

The next evolution is that you are confident enough to take on bigger features or issues (mostly) by yourself. In doing so you will earn trust from others and, before you know it, other seniors and leads will treat you that way.

You need to put yourself in a position where they can assign something to you and basically forget about it — they are busy and shouldn’t have to micromanage you. Of course, it’s fine to ask for help if you get stuck or need some fresh eyes to look at something, but generally they expect you to come back with a solution.

This can be scary at first, but don’t forget your team is always there to help you should you need it, and after doing it for a bit you will be more comfortable and start to really enjoy delivering whole solutions to often very complex problems. Others in the team will notice and soon your problem-solving skills will be in high demand.

2 — Anticipate more perspectives

As a software engineer it’s easy for you to think like one — that has loads of perks as you painlessly navigate complex systems on a daily basis and are able to fix your friends’ printers by installing the appropriate drivers (possibly… don’t ask me).

Part of the job teaches you to think like a user — you know the user stories “as a user when I …” — which is crucial in delivering good end products.

The next thing you should keep in mind when approaching weird edge cases and sometimes crazy-sounding business requirements is to ask yourself: “Why is this a thing?”

No business wants to build anything with needlessly complex business rules and limitations –there are always good reasons for them. Often if you ask the right questions you will find out why these limitations exist or why the business rules are what they are.

Then it becomes much easier to find the right solutions, not just mangle something together based on a partial understanding of the business needs.

Who knows: you could even use your problem-solving superpowers and come up with better ways to overcome the real limitations, thereby removing the weird business requirements all together.

It’s the same story with all stakeholders. The analytics and data crew might ask that you refactor your code a bit and add some more tracking, maybe even reducing your perfectly tuned code’s performance slightly (argh!). But by doing so the analytics crew can make better dashboards and gather user insights, so the marketing team can tune their marketing, leading to product growth (backed by solid data) that the department heads can take to the board, making an even stronger case for more budget in your project owners’ pocket, allowing you to build even more cool stuff.

So yes, I will add that bit of analytics code, thank you for asking.

3 — Speak up

Speaking up sometimes seems like it’s the hardest thing for a dev to do. We can understand cryptic programming languages and pick up new ones in hours, we can talk for days around fully conceptual ideas and the logic behind our solutions, we can even install the appropriate printer drivers (well… some of us).

Yet there you are again in that planning meeting: the team is faced with an issue and no one really seems to know which way to go. You have your own approach in mind and it seems like it could be the perfect fit, but what if it isn’t? So you don’t say anything.

You need to realise everyone feels that way all the time, it’s human nature. It’s just that some of us have got to the point where we realise that, no matter how bad we think it might be if we chip in, it almost certainly won’t be.

So we spoke up once and everyone loved it: there was applause, beers, pizza, a new Slack emoji, a statue was built.

OK, I’m joking, but you get the idea. Once you are comfortable in your team there is no reason to be scared to speak up when you have ideas or different opinions, the team will only respect you for it.

The more you do it, the more you will want to, and the sooner others will come to admire your insight and approach, often seeking it out when they approach new problems.

4 — Be honest and own up

The continuation of speaking up. Sometimes you will have spoken up and you might have been wrong, or having spoken up you get asked a follow up question which you don’t know how to answer.

Oh no there it is — world shattered, just like you feared.

No! It’s perfectly fine and absolutely human to not always have all the answers or to be wrong. We all are, all the time. Here’s where the trick comes in: you use this to your advantage.

Admit you don’t know, but you know who might know, so you redirect the question or put them in touch with whom they need to ask. No one will bat an eyelid, so not so bad after all?

Admit you were wrong, this shows an incredible level of maturity and responsibility. Others won’t laugh, in fact their respect for you will skyrocket.

I once joined a very high urgency team call with an angry PO due to an issue on production. It was partly my fault, so I owned up immediately, I didn’t try to come up with some cover story blaming the process or lack of clear acceptance criteria for this use case.

I probably should have caught it and I didn’t: “I’m sorry that’s on me, I’ll fix it.” You know what the angry PO did? She instantly became the very understanding PO, apologetically blaming the current process for the issue occurring, going on to defend me from, er, herself? By owning up I won heaps of trust.

Now I don’t recommend deliberately breaking production to try to win trust, but you get the point. You will be wrong or break something or be caught off guard at some point. It’s up to you how you handle that situation.

5 — Build silly side projects to stay fresh

As a senior it can seem like you’re fighting an endless stream of new technologies and tools that you are supposed to have mastered or, at least, be able to use effectively.

On top of that, the sequence of events will often be wrong. You will have to take ownership of a chunky piece of work, sometimes using technologies you’ve never even worked with, and you’re expected to complete the work to your normal high standards.

Impossible? No. Time consuming? Yes, only you don’t always have the luxury of time.

This is where side projects and quick proof-of-concept projects come in to keep you on top of your game. You need to keep your ears to the ground for new technologies and, if something comes along that you want to explore, go for it! Build something silly, even if it’s just to teach yourself how to use the shiny new tech.

Over time these random projects will add up and, before you know it, you can figure out new technologies in no time.

Conclusion

I bet you thought this was going to be filled with technical deep dives and complex ideas you need to master. Not so, it’s really rather simple.

Own and take pride in what you’re doing, appreciate the bigger picture, be part of sharing ideas and problem solving, build trust with your colleagues, and don’t forget why you got into this career in the first place: to play with cool tech.

--

--

Zone
Zone

Written by Zone

We write about customer experience, employee experience, design, content & technology to share our knowledge with the wider community.

No responses yet