Cover photo credit: Studio Republic

Congratulations on your new developer job offer! It is natural to feel an equal mix of excitement and nervousness; after all, taking on a new opportunity usually means changes such as integrating into a new team, adapting to new ways of working and potentially a new city... the list goes on.

As someone who is about to go through that process again (at the time of writing), I want to take the opportunity to reflect on five things I wish I knew or did when I joined as a new developer in my last team, with the intent of adding to this as I discover more.

To future me and especially any developers starting your first job, I hope you will find this useful. Without further ado, let’s get into it!

1. Add to the onboarding documentation

Unless you are starting in a brand new team, the chances are they will have some onboarding documentation which will help you get started with setting up your machine and get a better understanding of your team’s working style.

Read through them carefully and use them to your advantage! Highlight anything that seems unclear to you - this will give you good starting points to come up with specific and meaningful questions before asking Google, Stackoverflow or your teammates for help.

Once you have resolved the issues from the questions raised, offer to contribute and add that newfound knowledge back to the onboarding documentation! This will not only help retain knowledge within the team, but also new developers joining the team afterwards will have the answers to (very likely) the same questions or problems you faced before.

Adding to the onboarding documentation is a great way to consolidate the new knowledge you have learnt. The process of trying to explain how you solved the problem (and why it was one) puts you in “teaching mode”. As much as it sounds like a paradox, being in “teaching mode” is effective for learning since it focuses your brain to think critically before you write anything down.

Contributing to the documentation as you gain some new knowledge also has the added benefit of it written in a beginner’s mindset. In other words, you are more likely to write something in a way that only basic knowledge is required to understand the explanation, which will help to make the documentation more accessible for new starters. This is also a good time to spell out any abbreviated terms that have confused you so subsequent new starters don’t have to go through the same process again.

2. Start exploring with the unit tests first

Finding the appropriate place to start exploring a new team’s codebase can be challenging as the code and set-up are going to be more complex than personal hobbyist projects. Fortunately, most teams understand that and so it is unlikely they will expect you to make big changes from day one!

The best way to start is by picking up something small, usually bug fixes, that your team needs to get done for the current sprint. This will give you a good entry point and some focus on the specific parts of the codebase you need to understand before carrying out the fix.

Now that you have identified the parts of the codebase you need to look at, start looking into the files that may contain the buggy code. Try and look at the functions (and classes too if working with object-oriented languages) at a higher level first to see how they interact with each other, and only delve deeper into the function’s implementation details if necessary so that you don’t feel overwhelmed early on.

Once you have found potential functions where the faulty code might be in, start by looking into the unit tests for the relevant functions. The unit tests are a good place to start as it should show you the function’s behaviour and how they are intended to be used.

Reading through unit tests will also help you identify the appropriate place to start writing additional tests to try and reproduce the bug. More complex bugs may not be reproducible with unit tests alone, but if possible, adding unit tests as you fix the bug is generally a good practice. They ensure that if the bug appears again in the future, your new test cases should catch them before they end up in production.

3. Ask questions

This may sound like an obvious one, but honestly, asking questions is one of the best ways to integrate yourself into a new team. Good questions deepen your understanding of how your team works, why the codebase is structured in a certain way and any background information about the product that you won’t find from doing a Google search alone.

When asking questions related to why the codebase is written and structured in a certain way, it is important to do it with tact and empathy so you don’t come across as harshly criticising your team and put them in defensive mode. Instead, you want them to help you so you can get up to speed as quickly as possible!

Ultimately, no developers want to write bad code. While certain ways of structuring and coding styles may seem sub-optimal to you, there may be good technical reasons for doing so at the time (e.g. certain language features weren’t available). Respect your team. If you come up with ideas of improvement while trying to gain an understanding with your questions, suggest these in the next team meeting!

In addition to the onboarding documentation (see advice #1), the commit history of the codebase can be another great resource to use to come up with meaningful questions. The great thing about commit history is that it tells you exactly who has worked on certain files. If those people are still part of your team, they are probably the best people to ask your burning questions about that part of the codebase.

From experience, some good questions to start with include:

• What software development methods do they follow?
• How and why are certain decisions made (e.g. coding styles, structure, the software’s architecture etc)?
• What is the history behind the naming of certain internal terms?
• Do people prefer to work individually (and get help when necessary), or do they work better in a pair programming setting?
• How are product decisions driven? Is it a collaborative effort between a product’s owner and developers?

4. Know your teammates

Building the company's product will involve working with your team, so get to know them! I am not saying you have to be best friends with everyone in your team, as some people may prefer to keep their work and social life separate, but having good working relationships with your teammates will make your life easier (for reasons outlined in previous advice) and more enjoyable.

A good place to start for knowing your teammates better is by looking out for any social or watercooler channels that your work chat may have. These will often range from people informally organising a time to make coffee together, having a game of pool/foosball (or whatever tabletop games your office have) to having lunch together. When you see an activity being planned, respond to it and agree to join in.

For those of you who are more introverted, ask if one of the teammates who sits next to you can come along and introduces you to the rest of the team to ease the process. Hopefully, this shouldn’t be as tricky as you would have "broken the ice" already when you asked them for support initially. People in tech are generally quite friendly and receptive to new people joining their team, so they will understand the "newbie nerve" (I totally made that up). By the time you have been out with the group a couple of times, you will feel more at ease again.

5. Seek regular feedback

It is easy to come in the office, work away, leave and repeat, thinking that you are doing well. But really, how will you know for certain that your company and line manager think the same so that you will pass probation soon? You need their feedback!

Seeking regular feedback will help you focus on the settling in process, as feedback meetings tend to be where you set personal goals to aim for in between. They are likely going to be one-to-one meetings with your line manager too, so apart from getting feedback, these are also opportunities for you to raise any concerns and ask for any support you may need to help you succeed in the team.

Although this post is meant to focus on advice for developers settling into a new team, I want to stress that getting regular feedback after you have passed your probation, year’s work anniversary etc. is equally as important. In particular, once you have passed probation, these feedback meetings can be instrumental in getting your next promotion, pay rise and your career progression generally.

As the unofficial sixth advice, in addition to support and training you may need, I would recommend keeping track of small wins you have achieved such that by the time the big review meetings come around, you will have built up a strong body of evidence to support your next career move.

Is there any advice I have missed out that you think would be beneficial for developers settling into a new team? Let me know in the comments below - I’d love to hear your thoughts! 😊