Changing your job or team often means changing the current project. It can be a difficult situation for most, especially at the beginning. Also, from the perspective of the team we are joining. What should we do to get noticed at a new project?
Recently, I also changed my job. It wasn’t my first time. In this article, I will provide suggestions that may make your start easier.
Don’t try to impress
When we become familiar with a new project, we often see code that is not perfect. One of the worst things we can do is harshly criticize faulty practice. It may be surprising and a problem avoidance, but that’s not what I mean. At the start, we are new, probably unknown. If we have to refer to something, let’s do it gently. This will not alienate the entire team. Starting a discussion and proposing potential solutions can be a much nicer solution.
Each project is different and has a different history. What worked for one of your projects may not necessarily be universal. Before starting a “great refactoring”, it is worth finding out why something was done this way. You may find that something you’ve noticed is only proof of concept or for internal use.
The new project means new working conditions. Knowing the stakeholders and their goals can help you understand why your code isn’t as good as you’d expect. Often some shortcomings are accepted to deliver business value1.
Keep an open mind and try to understand the team and the project instead of impressing them. This will allow you to become a team member instead of being the “smart new one”.
Ask questions
A new project is often about things that we have never done before and do not understand (entirely). By learning about the history and design decisions made in the code, we can come across completely incomprehensible things. This rule is essential not only when you change the project but always. When we don’t understand something, it’s not very clearly prepared, we should ask.
What do we gain by asking the right questions? First, we indicate that we are independent and do not need to be led by the hand. Due to our fresh perspective, we can see something that needs improvement. When asking, we should find out why it has been prepared this way, rather than criticizing that it is wrong or not.
Ask for help
When we have a problem, ask for help. When we don’t know how to move on, ask for help. Just don’t understanding, also ask! When we sit with a problem for a long time, we may not notice some obvious facts. Sometimes you can solve something in a quarter of an hour with the help of another person.
Asking your team for help also helps eliminate uncertainty. When a new thing takes a long time, no one will keep checking us. Knowing that we will be asking, the team can focus on other tasks.
Admit your mistakes
One of the most difficult things in life is admitting when you are wrong. From an early age, we are taught not to make mistakes. However, should it be so?
Instead of avoiding mistakes, we should learn from them and not make them again. Experiencing this the hard way is perhaps the fastest way to learn. One mistake in production is enough for most of us to approach subsequent changes much differently. The more significant the failure, the greater the lesson we can learn.
At work, nobody expects us to understand everything, especially at the beginning. Be honest when you can’t do something. Maybe it will surprise you, but the team will quickly see if you can or are just pretending and speaking well. When we cheat, we put ourselves in a losing position.
Admitting own ignorance is also a learning opportunity. By collaborating with a team member, we can both learn something new.
Not just code
A programming project is not just code. You can be a super-specialist who handles all documentation, programming language, and thousands of libraries. However, understanding the business domain and the purpose of the project is also important.
Most projects are built to solve a specific business problem. The team expects the new person to quickly grasp the project, understand the business domain, and support them.
How can we achieve this? Most of us work in Scrum or similar. Preparation for meetings: daily, demo, retro, and whatever else you have can be the first step. Getting acquainted with the tasks and checking the pull requests (code review process) can give you a huge boost of knowledge.
Think about team success
Programming is teamwork in which the whole team should help each other. When trying to stand out from the crowd, we often think only of ourselves. When a project is successful, so are we. The right commitment can make a difference.
It is worth remember to rest and avoid the rat race2. It may be surprising, but it makes our start worse. Being tired, we are less focused and more nervous.
Summary
I wanted to prepare a list of what to pay attention to when you are changing the project. The article was based on my own experiences and conversations with the team. Maybe you were the bad guy who wanted to do everything differently? I was once. It’s a shame.
-
Pareto principle can be an example that it may not be worth striving for perfection. ↩
-
Rat race is an endless and pointless pursuit. That leaves no time for relaxation. ↩