How You As a Junior Developer Can Immediately Provide Value When Joining a Team

Being a junior developer is hard. Joining an engineering team as one is even more difficult. There is so much to learn, so much to absorb, so much to be taught, so much to get used to, and the list goes on. As a junior developer, being able to go through all of this and being able to make it out alive feels like an achievement in itself. Two years ago, this was also exactly how I felt during my first job.

Because of all of the scary stuff that can happen when you join a team as a junior developer, a lot of the more positive aspects are often overlooked. It is therefore not weird that people rarely consider the value that junior developers can provide to a team. Even for the juniors themselves, it will most likely not be something they put on top of the list of what they can do in these scenarios.

Most likely they do not even think that they can provide anything meaningful and feel like they are a liability until they are onboarded fully onto the team in the distant future. This is also how I personally felt two years ago. How could I, someone without any prior practical experience who just started his first job, possibly provide any meaningful value to the team I am joining? Obviously, I would love to be able to make an impact, but with everything going on I told myself that I would only be realistically possible after several months.

This is also how it went during that job, but not necessarily because it was not possible during those months. Rather, it was my mindset that there was no way for me to provide value that held me back from actually doing so. Two years later, I started at a new company and joined a new team. Because of how new everything was, I felt like I was basically back to being a junior developer again.

Some people would argue that with two years of work experience I can not be considered a junior developer anymore, but I do not think that is so clear-cut. I do not consider the amount of work experience the determining factor and think it also depends on the context. Changing jobs during the pandemic felt like a hard reset of everything I experienced before that. Everything was new — the company, the people, the team, the environment. Going into it, it definitely felt very similar to starting my first job.

But one thing was different: I went into it without the assumption that I could only provide value to the team after a certain amount of time. Based on my first experience, I learned several things about providing value to a team as a junior developer. The first thing is that I could provide value to a team as a junior from the start.

That is also my first message to you — just because you are a junior developer does not mean you can not provide value. There is actually quite some value that a junior developer can bring to the team from the moment they join. In fact, I think that a junior developer can bring a lot to the table for a team, which in certain cases can also only be done by them.

The next steps, which are probably even more important, are knowing what kind of value you can bring to the team and how exactly. Using the experience that I have, I will go over these topics in this article and share what I have learned over the years. Using this knowledge, I hope that you as a fellow junior developer can gain more confidence and start making an impact from day one.

Question The Status Quo

There are two things certain when you as a junior developer join a team: you get a job and the team will change. The former is definitely worth celebrating, but here we will discuss the latter. No matter how trivial you think your arrival to a team is, I will tell you that it is everything besides non-impactful. Although it might not be immediately noticeable, a new developer joining a team always has an impact in some shape or form.

Every team has a certain way of functioning, working, and collaborating. The longer and more a team works together, the more they will get used to each other and form a culture inside the team — the status quo. This is inevitable for any team and an essential process to becoming a more coherent team.

But there is also always a potential risk long term. If a team works together for a long time, people will start embracing each other’s flaws rather than addressing them. They will get used to a certain style and way of working, becoming less critical in the process. The team will feel comfortable and no need to elevate themselves further because everything is working out. In the end, this can cause severe risks to the quality of a team and potentially stagnate or even hold the team back.

As a junior developer, the fact alone that you are joining a team is already a change that makes sure that the team does not become too comfortable and fall into the trap of stagnation. While you might not feel it, your existence passively questions the status quo.

But you could go even further and actively challenge it. As a junior developer, you will be learning a lot and trying to adapt to the team, but you should also be critical. Look for things where the team is lazy, has bad habits, is inefficient, or can improve at.

The most common indicator for this that I have encountered is whenever I asked a question or noticed something strange, the team responded with something along the lines of “this is how we have always done it”. This could indicate that a team has become too comfortable around the current process, less critical of their surroundings, or have already started to stagnate.

Every team has this potential risk lurking around. It is an often inevitable consequence of working together for a long time and becoming too comfortable with the status quo. But you as a junior developer joining a team can shake things up. Your presence alone will start putting cracks in the status quo. If you realise this and the fact that you play a key part in it, then you will be able to recognise those cracks, put changes into motion, and make an impact.

You Are A Breath Of Fresh Air

One of the most crucial skills that we as developers have to have is adaptability. The field of software development is fast-paced, constantly moving, and ever-evolving. New libraries, frameworks, languages, concepts, technical features, and so on are introduced periodically. Therefore developers must be able to stay up to date and move along with the field.

But for an engineering team, it does not always apply that constantly adapting to the newest trends in the field and state of the art is ideal. More often than not, being able to guarantee stability and reliability of the product goes above staying up to date with the newest trends in the field. The ideal scenario is being able to do both, but in reality, this is rarely feasible and priority is given to the former rather than the latter.

Under normal circumstances, this is completely reasonable. From a business and development perspective, it is not beneficial to constantly adjust your stack or change things up. But it does become an issue when this causes a team to stagnate their stack for too long. When a team rarely adopt new things from the field, the developers of the team have no incentive to keep up with the state of the art.

This will in turn create a vicious circle — the developers are now less incentivised to follow the field, which leads to them having less knowledge about new technologies and tools, which leads to more difficult decisions and less adoption of new technologies and tools due to that lack of knowledge.

While the above is all theory on paper, it is actually not as uncommon as you think in the real world. Even when I started my first engineering job as a front end developer, I experienced exactly this. Our stack was by no means terrible, but it was a bit outdated in some aspects. As the junior in the team, I was really surprised, but the other developers of the team got used to it over the years and thus weren’t bothered by it.

This is something that you will see often: a team that got used to the current stack over the years and is disconnected from the field to a certain extend. They will not necessarily be against the idea of updating various parts of the stack, but they don’t know what alternatives are available, are fine with the status quo, and don’t know the value that new tools and technologies can provide.

This is where you as a new member of the team can jump in start providing value with the knowledge that you have. Because you are a junior developer, you will have a different view of the field compared to members of the team you’re joining. This can be because you recently joined the field, because you dove into technologies that have a strong audience right now to increase your job odds, or a whole lot of other reasons. The reason exactly does not matter, but there is a high chance that you have a different, very likely also more recent, grasp of the current state of the art in the field compared to the team.

Using that different and more recent grasp of the current state of the art in the field, you can provide a lot of value to a team that is stuck in the vicious circle that I mentioned before. Basically, you are a breath of fresh air that can sweep through the team and clean off all the dust. By comparing your view of the field and the team’s stack, you can identify the parts that can most benefit from upgrades or changes, and also how they will benefit the team. This is possible because you have more knowledge about (and experience with) the current state of the art technologies and tools in the field.

Every engineering team has difficult decisions to make, including how often they will adopt new technologies and tools in the field. In this process, it’s not uncommon to see teams have a conservative approach. But this can lead to the team opting out of following the state of the art, become disconnected from the field, and being stuck in a vicious circle between these two. As a junior developer, you can be a breath of fresh air that brings in more state of the art knowledge into the team. By critically using that knowledge, you can help a team in a way that they didn’t even know was possible. As a junior developer, you can play a key part in breaking up this vicious circle for the team.

Test The Team’s Communication

Let’s be frank, developers are not famous for being great communicators. Although we work in teams, communication between team members can still be limited. As developers, we are often used to working on our own and focusing on our own tasks. Especially in this day and age (with the COVID pandemic going on), many of us will be working remotely from home. Communication between team members will be through online platforms and most of the time in textual form. This is unavoidable given the current circumstances, but also imposes another layer of ambiguity on top of communication.

Despite everything, proper communication still plays a crucial part in a team being able to function well. A team without proper communication between the members can impose significant risks long term for the team. Single point of failures, low truck factor, individual decisions, the team getting out of sync, and isolated code ownership are all examples of risks resulting from infrequent and improper communication.

All of these I have experienced first hand, which was definitely not a fun experience.

On top of everything, teams that have been working together for a long time also face the risk of growing too accustomed to each other’s communication styles. To a certain degree, this is perfectly fine as the team will be more in sync, keep the ball rolling smoothly, require less unnecessary back-and-forth’s, and in general work better as a coherent unit. But a team can also grow too accustomed to each other, and compensate or ignore other’s flaws. This can lead to a lack of communication, a lot of assumptions, avoiding communication, a lot of miscommunication, and so on.

As a junior developer joining a team, these will make your onboarding a lot more difficult. It means that a lot of information is either implicitly communicated rather than explicitly, which makes it very hard for you to pick up, or not communicated at all, which basically makes your job impossible. But there are things that you as the junior developer can do to address this issue and help out yourself, future hires, and the team.

Obviously, you can’t ask for something that you don’t know of. But there will always be interactions between the team that you might find confusing, don’t understand, or think can be improved upon. The most important thing is to highlight them, ask questions, and bring them to the attention of the team. Do not fall into the trap of assuming that you are not in a place to question a team and thus contributing towards the communication problem as well. More often than not, a team is not aware of the flaws they have and won’t know until someone mentions it.

To help the team improve in this aspect, you as a junior developer can really take the initiative in this manner. Be wary of moments of communication that are confusing, non-existent, or are backed up by a lot of assumptions. If you come across them, make sure to bring them up to the team to address. Don’t be afraid that you are not in a position yet to question the team. Because you are the new kid on the block, you have the most objective perspective and people will expect you to have questions. Highlighting these communication issues will only benefit the team long-term and also mark your impact on the team.

Challenge The Team’s Current Mastery And Knowledge

In the context of an engineering team, having mastery and knowledge about a certain topic does not only boil down to whether you’re able to apply it during development. Frankly speaking, every engineer is capable enough to use Google to search for a topic, read some documentation or articles about it, make use of code examples, and apply what they learned at the moment.

The question is: are they likely to remember what they have learned somewhere in the future? Claiming mastery and knowledge over a topic is more than just being able to apply it once in a Merge Request. There are a lot more factors like knowing alternatives, in which scenarios which alternative makes more sense, and how to implement the other alternatives.

All of those factors come from an individual perspective, but some factors are more important in a team environment. Think of being able to reproduce it in the future or being able to share the knowledge across the team. But to do so, the developer needs a way better grasp of the topic compared to just applying it once.

For certain topics, it’s perfectly fine to not have the mastery and knowledge ready at all times and rely on external resources. Nobody expects someone else to know an entire API by heart for example. But in every team, certain topics are fundamentally important. Think of topics that cover internal knowledge, are related to the team’s processes, or involve technologies that are used daily. In those cases, it’s quite important for the team that its developers have a solid mastery and understanding of the topics.

As a junior developer, you can challenge the team’s current mastery and knowledge of topics by doing something that we have already mentioned before — asking questions, a lot of them. Keep asking questions and see how different members of the team can answer your questions. The good thing about being new to the team is that everyone expects you to ask questions. Make use of this and question everything until they are totally clear to you. Not only will they benefit you, but if someone is not able to answer a fundamental question properly, then you bringing it up will shed light on holes in the team’s current mastery and knowledge of those topics.

Final Thoughts

Being a junior developer and providing value to a team is not often associated together, to the point that is also the mindset that junior developers have. But based on my experience, I do think that they can provide a lot of value to an engineering team and in certain ways is exclusive to their position. In this article and based on my experience, I went over how I think junior developers can provide value to an engineering team. These are questioning the status quo, being a breath of fresh air, testing the team’s communication, and challenging the team’s current mastery and knowledge of certain topics. All of these involve making use of their position as a new member and can be applied from the moment they join. Being a junior developer doesn’t mean you’re always a liability. With the right mindset and actions, you can be an asset instead of a liability and provide value starting day one.