How to go from junior to senior developer

☝️ A step up

The biggest and most daunting step in anyone’s career as a developer is the first one—from not being a developer at all to being a junior developer. A great deal is rightly written about that step; what to expect, how to prepare, how to succeed. Less is written about the next step: ditching “junior” from your job title. But this step is just as important and can seem just as shrouded in mystery as the first, so that’s what I’m going to talk about in this article: what’s going to change when you stop being a junior and why you will definitely be absolutely fine.

what’s going to change when you stop being a junior and why you will definitely be absolutely fine

Being a junior developer is about learning. Depending on the path you took before you landed your job (whether you did a computer science degree, attended a coding bootcamp, were totally self-taught, etc), any number of the things you do dozens of times a day as a developer could be brand new to you. So being a junior developer is primarily about becoming competent at the fundamentals:

• your programming language of choice
• source control
• testing
• system design
• automated deployments
• etc...

What everything in this list has in common is that they’re all expressions of the fact that you’re moving away from a position defined by learning and towards ones which are defined by expertise (though this certainly isn’t to say that you stop learning when you stop being a junior, or that you don’t have any expertise as a junior!).

👨‍💻️ Code reviews

One obvious consequence of becoming a competent coder is that you’re seen as being capable of reviewing your peers’ code. Exact code review procedures can vary in all sorts of ways and you might have already done some as a junior, but you can expect to do more of them as you progress, and that your reviews are likely to carry more weight.

This can feel like a lot of responsibility! Code reviews are important and very visible—your reviewee and likely anyone else who works in that repository can see what you do and don’t comment on— so it’s easy to feel like any mistakes you make will be obvious to everyone on your team and then they’ll always think you’re that idiot who suggested refactoring a single if/else statement into a switch.

they’ll always think you’re that idiot who suggested refactoring a single if/else statement into a switch

Reviewing code is a skill, and like any other skill you need practice to improve. Unlike many skills, though, it’s very difficult to get any good at reviewing code until you’ve become competent at another skill: writing code. So the thing to understand here is that you’ve earned your new responsibility specifically by merit of your competence. Focus on that and enjoy the fact that even though you have a long way to go in your journey, you’ve reached a point where you’re being given work not simply because it will be a good learning experience for you, but because you’re the person with the expertise to do it!

😳 Higher risk work

As you progress in your career you’ll work on increasingly high-risk tasks. You’ll likely start on small enhancements or bug fixes to non-critical systems; tasks you could hypothetically mess up without causing too much chaos. Then, as you gain experience, you’ll start to work on increasingly important features of increasingly important systems and on tasks it would be increasingly difficult to roll-back if something did go wrong.

This can be intimidating for very obvious reasons. But just as with code reviews, you’re being given these tasks because you’ve already proved yourself to be the person for the job.

you’re being given these tasks because you’ve already proved yourself to be the person for the job

The other thing to bear in mind as you take on these bigger pieces of work is that it’s okay to move more slowly when the risks are higher. It’s sensible, even! Spending more time researching options, writing unit tests, and manually testing your solution before you deploy it are all to be expected. Remember how scary it was when you first started pushing code to production? Eventually you overcome that by learning that these practices lend security about code quality and knowing that if you do them well then things are relatively unlikely to go too far wrong. The thresholds for security are higher with bigger and higher-risk work, but you’ll learn to meet them just like you learned to meet the thresholds for smaller tasks. Take your cue from your peers—what do their test suites look like, for example? If it’s good enough for them, it’s probably a good place to start!

👨‍🏫️ Training juniors

When you started as a junior developer, you’ll hopefully have been trained by more senior developers on everything from features of the programming languages you’re using to the structure of your company’s codebase. I.e. all the sorts of things that being promoted proves you’ve become competent with. As such, you can expect to start paying some of that training forward to the next generation of juniors.

it can be very satisfying to have such a concrete demonstration of how you’ve progressed

For lots of people this is one of the most gratifying parts of progressing in seniority. Even aside from the warm fuzzies associated with imparting knowledge and helping people, it can be very satisfying to have such a concrete demonstration of how you’ve progressed;

in this case you can likely remember very clearly when everything seemed overwhelming and it felt like you needed help from a more senior developer to achieve anything substantial, and now you’re that more senior developer!

That recollection is an asset to you as a teacher, too. It will give you empathy for the juniors you train and the position they’re in. Hopefully you can remember what sort of teaching was most useful for you and which things you found particularly confusing and use that knowledge to inform how you go about training new juniors.

How much training you give at a given level of seniority will vary from company to company, but you should certainly be prepared to take a leading role when pairing with juniors. Whatever the exact context, you’ll be explaining things to and answering questions from junior developers. In fact, it won’t only be juniors you do those things for, because …

🦉 Your insight is increasingly valued

As you move away from a junior job title and eventually towards ones with words like “senior” or even “lead” in them, one thing I can tell you with absolute certainty is that you’re going to get asked more questions. Partly because there’s a whole job title’s worth of developers who are less experienced than you now who will be looking to you for advice and assistance. But also because as you move into roles defined by your level of expertise your peers, more senior developers than you, and your colleagues in non-technical roles will turn to you for that expertise increasingly often.

This can take many forms, from being asked “could you take a look at this React component? My useEffect doesn’t seem to be firing” to being invited to take part in a planning meeting to lend your technical expertise in a discussion about how some future work might be done.

you’ll probably start to be assigned some more nebulous tasks and given the opportunity to figure out more of the detail yourself

The nature of your work is likely to change, too. Where you might previously have only worked on small, well-defined tasks, you’ll probably start to be assigned some more nebulous tasks and given the opportunity to figure out more of the detail yourself.

You’ll also likely be assigned more work involving research. Tickets with names like “Research possible implementations for …” and “Investigate options for form validation libraries”.

This sort of work is likely to be your first opportunity to have a big impact on the direction of development in your company. It will also provide opportunity for you to become a subject matter expert on some library/concept/language/area of your code base (depending on what you’re researching and what for). Of course, this inevitably leads to your insight on those areas being valued even more, which in turn results in your insight being even more sought-after!

😎 Beating imposter syndrome

These are only a small number of the ways your job is likely to change as you leave your “junior” title behind. They’re all natural changes based on your increase in expertise since you started your career and they all represent great opportunities to for further growth as a developer. They’re also all rewarding in their own right! The biggest hurdle to you enjoying that is likely to be nerves about whether you’re ready for these changes and the new responsibility they entail.

you’ve been put into that position by someone with more experience than you

We all suffer from imposter syndrome sometimes and on those occasions I find this thought comforting: whatever role you’ve been promoted into, whatever work you’ve been assigned, you’ve been put into that position by someone with more experience than you.

That is, someone who knows better than you what that role or work requires, has watched people progress as developers before, and has judged that you meet all the criteria. You might not feel that way, but there’s no sense arguing: they simply have more data than you!

All there is for you to do is try to enjoy your new role and the responsibility and trust that come with it. And try to remember this advice; before long you’ll be the one giving it to a (soon to be ex-) junior developer!