A self-onboarding guide for Software Developers

You rocked the interview and landed your dream job, it’s your first day, and you are ready to start… but, now what? It doesn’t matter if we are at the beginning of our careers or if we are already advanced software developers: starting a new job is stressful. The anxiety caused by so many new things to learn, wondering about our manager and colleagues’ expectations for us, wanting to make a good and lasting first impression… very often it’s a lot to take in, and many of us have been there. But is there a way to escape the pain and have a seamless onboarding?

When it comes to a new job we all wonder at some point how we are doing. Are we meeting the expectations? Are we delivering value? As a software engineer, I’ve been in both sides of the onboarding process: I have joined a new team a few times, I have helped people join a new team many more. This post is my own, very opinionated guide, to a successful onboarding, and it’s meant to give software developers a few tips for their first 90 days in a new job.

Priorities, expectations and productivity: what should you do first, what are your manager and teammates expecting from you?

Every company has its own onboarding process, some have “starting projects” for new engineers to complete during their first 2 weeks, some will assign you an “onboarding buddy”, some will even organize trainings and hire software engineers in batches… At Hivestack (my current company) new devs will start their first day with a meeting with their manager, where they will be let known who will be helping them during their onboarding.

No matter what your new company’s strategy is, just make sure you know it. Ask how long the onboarding process is supposed to be, who you should ask your questions to, and what the expectations are for you during the first couple of weeks. Make sure you know who is directly responsible for you, and then ask that person for feedback at least once every 2 weeks during your first 3 months.

During the onboarding period it’s harder to evaluate your progress by your own because it’s easier to get sidetracked by so many new things. Asking for frequent feedback will help you stay on track.

Directing your efforts and learning about the product

There are 2 things I recommend trying to avoid

• Asking the same questions over and over
• Accomplishing tasks very fast, at the expense of not gaining much understanding about the product

During my years as a software engineer I have seen this story too many times:

Mark (new dev we are onboarding) gets assigned a task, however the context for the task hasn’t been written anywhere, it’s a simple enough task that any software engineer in Mark’s team should be able to finish it in less than 1h, but Mark has been with us for only 2 weeks now, he doesn’t know the code base, and he is still learning his way around the product. So Mark asks Clara, one of the senior devs in the team, for help. Mark and Clara then have a quick call where Clara explains what needs to be done in order to accomplish this task. He takes notes carefully and, after the call, is able to successfully accomplish the task in approximately the same time any other senior member of the team would.

However, when Mark attempts to start his next task, he finds himself in a similar situation, so he now needs to ask Robert, another member of the team, and after a quick call and a detailed explanation of what needs to be done, Mark is able to complete this task as well.

The only problem with Mark’s strategy is that he is not becoming more independent. In his efforts to complete his tasks faster, he is becoming dependent on other members of the team. He needs a step by step explanation of what needs to be done every single time, which also means he can not be assigned more complex tasks.

What could be a better strategy?

Here are a few tips!

Ask for context and not instructions

Understanding the code base is one of the first steps to become a fully onboarded member of a team. Take the time to learn how your team do things. Get someone to explain the project to you and then go through the code just to get familiar with the structure of the project, that will allow you to have a general idea of where the changes should be done for most of the tasks.

Read some code and then, read some more code

Take advantage of the fact that usually nobody is expecting much from you during your first few weeks. This is your opportunity to learn. If there’s some common sense in your company you will be assigned tasks that are easy enough to accomplish, take some time to locate similar pieces of functionality in the code. For example, if you are working on a backend service that exposes an API and your task requires you to modify an existing handler, you can go over other handlers with a similar behaviour.

Ask your questions (the right way)

After poking around and reading the code you realize your ticket is more complex that you thought? You have a general idea of where things should go, but you need clarification? Now comes the time to ask your questions.

Remember the other members of your team are also working on their own tasks, keeping that in mind at the time of asking questions will help you get better answers faster!

When asking your questions make sure you explain exactly what you are working on (and provide a link to the ticket, if your company uses a ticket based system), what you are trying to achieve and why you are unable to achieve it. It is important to let your teammates know that you did your best to solve the task on your own, and you already have some understanding from your own research. Make sure to provide this information regardless who you are asking your questions to. I have often seen new devs provide no context just because they are asking the person who created the task. Tasks (specially non-urgent ones) sometimes sit there for weeks before being assigned. Don’t assume the context for your task will be fresh in everybody else’s mind. If a senior member of your team needs to ask you too many questions just to understand what you are working on, you are not making a good use of their time (and your own).

Record meetings and calls

This changed my life, specially since I started working remotely.

At the beginning of my career as a software developer every time I needed clarification about a certain topic I would have a call with a senior member of my team and I would frenetically take notes. Many times there would be screens being shared and code being explained during those calls, I would try to write down the routes to the scripts (so I could go over them), the names of the important functions (so I could carefully read that code after the call) and the necessary steps to reproduce certain behaviour. It was often an overwhelming amount of information, and for those small, important details I missed in my notes, I would have to ask again.

Soon enough I learned an important lesson: we don’t like to repeat ourselves. And then I really understood that same lesson once I found myself on the other side of the table, explaining things to new devs. I have been recording my discussions with my teammates since then, I don’t need to take notes anymore, and I can always revisit the videos later on!