We all started there at some point, no matter how much a particular developer might know, or how long have they been working, everyone starts at the beginning, there is no way around it.

But if you’re right there now, getting started and wondering what you should be doing to jump into the next seniority within your company (that can be Senior, semi-senior, junior advanced, or whatever variation of the names you might be using), then I’ll try to give you some recommendations based on my prior experience and on what I tend to look for in promising junior developers.

You may find that some of these recommendations don’t apply within your context, and that’s completely fine, it’s not an all-or-nothing scenario, but rather more like a “you should aim towards some of these behaviors in the future” type of thing.

Autonomy

When you’re just getting started, having someone else holding your hand through the process of working on your task, writing your code, troubleshooting it, and committing it to the main repository feels good.

In fact, it feels safe. And that’s a great place to be. The problem with that is that hand-holding can only take you so far. Eventually, you have to show that through this process you’re also learning and applying what you’ve learned to solve other, new problems.

Don’t confuse autonomy with working in isolation without asking anyone for help, ever.

That’s just silly. What I’m talking about here is the ability to receive a task and work on it yourself. That also includes things like:

• Asking for clarification when the requirements aren’t clear.
• Asking for help when there is a problem you don’t know how to solve.
• Raising your hand and speaking up when you don’t agree with the objective of the task.

So you see, “autonomy” is not about closing your mouth and working, but rather not waiting on someone else to show you that the ticket is not clear enough and that you should ask for clarification. Or just doing what you’re told, even if you know it’s not right.

This is not something that you’ll develop suddenly from one day to the other, but rather you’ll be developing it your entire career. But through practice and experience, you’ll start adding a lot more value than what you can bring with your coding skills.

And I get it, it’s scary. Speaking up when you think you don’t know enough can be a terrifying experience. So try to consider the following tips:

1. Do it from a place of humility instead of arrogance. Don’t claim there is an external problem that’s preventing you from working, but rather that you’re unable to work with the current situation and would like to get some help.
2. There is nothing wrong with asking questions or requiring help from a colleague (we’re all constantly learning after all), just try to exhaust all possibilities before doing so. Do you have a question about solving a programmatic problem? Have you Googled the problem already? Do you want to understand how to write your commit message? Have you read the documentation already? Exhaust the obvious solutions to show your team that you’re capable of troubleshooting on your own and that you’re turning to them because you need their experience.

Autonomy is one of the key traits managers look for when thinking about promoting a person for a senior role. So the more you develop this skill, the more chances you’ll have to earn that next promotion.

Flexibility

I tend to favor this trait, but I know other managers don’t agree with me.

The point here is that a lot of developers tend to box themselves inside a particular technology. Instead of considering themselves as “developers,” they see themselves as “JAVA Developers” or “React Developers” or “.NET Developers.”

Granted, that’s your specialty, I applaud it, you’re great at that, fantastic. But if you’ve been around long enough — and chances are, you haven’t — you’ll learn that most technologies are very similar.

Once you know JAVA, making the jump into C# is not that hard, or even jumping to Node.js. There are concepts that are very similar, and others that you’ll have to learn. If you’ve been working on desktop applications so far, and now suddenly you’re asked to work on a web app, you’ll find yourself hitting your head against concepts such as HTTP Request, DOM, and others. But that’s just part of our industry: we’re always learning.

The worst thing that I can hear from someone is “but I don’t know how to do that; I’ve never done it before.”

Of course, you haven’t. No one has done everything, we’re constantly finding new problems to solve that we’ve never solved before. How boring would our profession be if we always have to tackle the same problem over and over again?

Embracing learning also makes you a very flexible developer. One that can quickly pick up new skills and technologies.

Mind you, I’m not saying that you need to know how to master a new technology in a week. What I am saying, is that given the opportunity, you should not run away from tackling something completely new and unexplored. Instead, you should jump head first, willing to learn.

Because of that mindset, I’ve worked with languages such as JAVA, PHP, C#, Node.js (or rather JavaScript in general), Python, a little bit of Perl, Ruby, and probably a few others I’m not remembering right now. Am I an expert on all of them? Heck no! I don’t think that’s possible. But I’ve learned something new from each and every one of those technologies. And most importantly, I’m able to jump into a project and help out if required. That’s a great value-add right there and the type of experience you should aim for.

Ownership of Your Work

This one is very related to autonomy, but I think it merits its own section.

As developers, we work on multiple features and sometimes even multiple projects at once. But there is a difference between doing what you’re told and working on what you’re asked.

The first one makes you a mindless coding monkey. Harsh, I know, but you’re just writing code to fulfill a task someone gave you without asking questions or raising your head from the keyword. It’s easy, so much so that a monkey could be trained to do it (probably an exaggeration on my part, but you get the point).

On the other hand, if you own your work, you’ll suddenly start to:

• Worry about what you’re implementing and why you’re doing it.
• Wondering about the impact your work will have on the overall product.
• Raising your hand when something around your work doesn’t feel right or could have a negative impact somewhere else.

See what’s happening? Because you now “own” your work, you’re not only fulfilling the “easy” part of it (writing the code), you’re also adding a lot more value to your team and project: you care about the project, and you’re looking out for its best interest.

That’s not something a monkey can do! That’s the kind of thing a senior developer would do. Coupled with autonomy, this is something we managers tend to look for in junior developers, so consider going that extra mile and try to be aware of how things fit together with your work.

Leadership

No, I’m not asking you to lead a team on your first job. Stop stressing about it!

Leadership skills are mandatory for higher roles in our industry, and my personal recommendation is to start working on them already, slowly but steadily.

Why? Because sadly very few companies have an actual training for new managers or technical leaders. Instead, these are skills you pick up “as you go.” So, what better time to start picking them up than now?

While autonomy is yet again, very related to this point, it’s but one of the many things you’ll need to become a tech lead.

Other abilities you might want to start working on (and practicing whenever you see a chance for it) are:

• Communication skills. A good leader needs to understand how to communicate with others. Both technical and non-technical counterparts. A great way to grow this skill is by having your own blog. Writing is a great form of communication and one you can practice for free. The more you write, the better at explaining complex concepts you’ll get. This is why I always say that every developer should have their own blog.
• Technical expertise. No, leaders shouldn’t be the “gurus” of their teams. I’ve written about this in the past, but leaders should know enough tech to understand the problems their team is facing and whether or not a solution sounds good. If you’re already worrying about improving your skills as a developer, this quality will come on its own, so you don’t have to worry about it too much. However, be mindful: if you think you already know everything there is to know about your field of expertise, then you’re working against yourself.
• Confidence in your skills. A very hard skill to grow, especially considering how impostor syndrome is so common in our industry. But a leader should be confident about their skills and their ability to lead a team. This is something you’ll gain through experience, but you’ll only get that experience if you look for opportunities to break out of your comfort zone.

These are all skills you’ll develop over time and that no junior developer should be expected to have. However, the more you work on them, the faster you’ll start showing your team (and managers) that you have what it takes for the next seniority level (getting slowly closer to a leadership position, if that is what you want, that is).

Don’t get me wrong, I understand how scary your first dev job gets, and how everything seems new and everyone looks like complete badasses who know exactly what they’re doing every second of the day.

But you should stop looking out for a while, and focus on yourself. If you’re interested in advancing in your career, focus on the skills I mentioned here, that while they might not be technical, they are very much needed and will help you advance a lot faster than watching that other tutorial on Flask.

What about you? Would you recommend any other skill for a junior dev to get promoted? Share it in the comments!