Throughout my 10+ years career as a developer, I've joined new teams on several times, and many new software engineers have joined the team I was previously a part of. I've noticed some common behaviours among them all that, if avoided, might take a person far ahead in their career.
It's perfectly fine if you don't agree with some of them before we discuss them all:).
Let's get started.
Make yourself at home
You might already have a buddy assigned to you when you join a new team. If not, make a point of finding one. He or she would assist you in adjusting to the team. Try to learn as much as you can about the project and the team.
Do your homework
- Try to understand, the problem the project is trying to solve.
- Try to understand, the way the problem is being solved.
- Try to understand, why it is being solved that way.
Listen more than you speak
It's critical to listen and absorb as much as possible in the beginning. This is not to say that you should remain silent. You'll undoubtedly have a lot of questions, and you should ask them, but the goal must be to understand the topic at hand, not to speculate on why something is the way it is.
Read more code than you write
Understanding existing code is more crucial than writing new code at first. The more code you read, the more familiar you will become with the codebase, which will help you in making right decisions.
Take a look at my personal experience with this -
Consider yourself a junior
Make it very clear that regardless of your level of experience, everyone on the team, including those with less experience, knows more about the project than you do. By becoming aware of this, you will be more open to learning about the project from everyone in the team.
Don't start complaining right away
You bring new energy and skills to the team as a new team member. To make an impression, you can start looking for flaws in the present structure and design right away. You might start complaining about them. Instead, look for explanations why this is the case. Understand that the code is constantly changing. Acknowledge that there could be legitimate reasons for all this.
Don't start recommending anything right away
You should be aware that you are a new member of the team. Team knows more than you do. There could be more compelling arguments for the design to be the way it is. Because you are unfamiliar with the complete product, your suggested design changes/refactoring may not account for all circumstances. Instead, start a conversation about your understanding and approach. Learn more about what might work and what might go wrong.
Locate and assess current solutions/libraries
When you notice a problem that occurs frequently, you may be tempted to fix it smartly. This could be accomplished by developing a reusable library. But, before you propose it, are you sure there isn't one already? Make an effort to see if one already exists that fulfils the same function. Determine if it can be used/improved to meet your needs. It is usually very easy to write new code; alternatively, make an attempt to reuse an existing one.
That's it for now.
I hope this would help you make a good start in your new team.
