My thoughts on getting up to speed when joining a new team
Starting a new job as a software engineer comes with a lot of excitement and uncertainty. It is a new ground and previous years of experience can reduce this uncertainty as most concepts already known usually stay the same. A
class remains a
function remains a
function, and an Android
Activity is the same android
Activity that has been used in the past.
Unfortunately, there are some instances when some of the experience gained cannot be directly mapped to the new project that is to be worked on. Roughly 80 percent of skills required to work on the project are known at the beginning and the remaining 20 percent required to become a domain expert are unknown. This is why most developers go through the onboarding process.
Onboarding, also known as organisational socialisation, refers to the mechanism through which new employees acquire the necessary knowledge, skills, and behaviours in order to become effective organisational members and insiders. — Wikipedia
To become an effective team member, there’s a time investment that must be made by both parties — the existing team and the new team member. This is to ensure that the new team member is brought up to speed on the internal workings of the codebase and software development culture of the existing team.
Having experienced switching teams and taking up a new job, I have come to learn a few things about developer onboarding. I will list and discuss what I think should and shouldn’t be done during this process. I will be coming from both sides — an existing team member and a new team member.
Things you should do ✅
- Ask questions: Your teammates expect this from you and are usually ready to help, let them know if you need clarification on any thing. Sometimes asking too many questions can make one feel like a rookie, even with many years of experience in their tool belt. This might be the reason why some new team members sometimes feel discouraged to ask questions but instead try to figure out things by themselves. That approach is not entirely bad but it is not that great too. It is time consuming and one might not be successful with figuring out how the system works by themself.
We get wise by asking questions, and even if these are not answered, we get wise, for a well-packed question carries its answer on its back as a snail carries its shell — James Stephens.
- Get practical: Reading code with no intent to update the code is boring. It can also be overwhelming because of the many unknown parts of the code that this activity exposes. I feel that it is better to get practical by tackling the easiest task that is available — the low hanging fruit. A task can take one into multiple parts of the codebase and this time, while reading the code, there’s a motivation to understand how it works.
- Provide assistance (existing team members): It is the existing team members’ duty to ensure that newer team members are brought up to speed. This can be done by ensuring that precise answers are provided, with some background context, when things aren’t clear to the new team member. However, there is a clear distinction between providing assistance and micromanaging, do not cross that line. Another great way to provide assistance is to ensure that there are up-to-date tests in the codebase. This way there’s an extra layer of confidence that a new team member can have when modifying intricate parts of the code.
Things you should not do ⚠️
- Get stressed out: This seem like an obvious thing not to do. I’ve realised that there’s a certain form of internal pressure that new team members experience while trying to get up to speed and become a contributing team member. Most especially when they are trying to prove that the organisation made the correct hiring decision. Take things one step at a time and in a few weeks, the progress made will definitely be evident.
- Be afraid to make mistakes: Everyone makes mistakes. Even the most experienced team member has made ridiculous mistakes in the past. This is why most standard tech teams perform code reviews and have code quality tools. Most of these mistakes can be spotted before weird bugs are snuck into the system. If you do make a mistake, learn from the mistake. Existing team members should help new team members to plan new processes so that the chances of any mistake being repeated would be near zero (read more here).
All of us make mistakes. The key is to acknowledge them, learn, and move on. The real sin is ignoring mistakes, or worse, seeking to hide them — Robert Zoellick.
- Set unrealistic expectations: As an existing team member, it would be unfair to expect that the productivity of the new team member would become like yours in a few days. Do not enable such kind of hostile environment which will cause the new team member to feel inadequate most of the time. There should be an acknowledgement of understanding between both parties whenever a task is given to a new team member during the onboarding period.
- Spread yourself too thin: In a bid to seem like a productive team member, new team members might be tempted to do many tasks at the same time. This is a recipe for disaster and my personal suggestion is to take things one at a time. The time lost to context switching might seem little but it adds up in the end.
The man who chases two rabbits, catches neither — Confucius.
That’s all folks. Bis zum nächsten Mal ✌🏽.