A new person comes to work. Wants to change everything right now because teamwork is completely different than (it seems) should. However, the team reacts hostile and, instead of change, there is a huge disappointment. Are you the kind of person who wants to change everything right away?
I want to raise the topic of how to get to know yourself in a new workplace. In my opinion, this is a great way to start your adventure in a new company. It will also come in handy when changing projects.
Let the team know you
If you come to a new project or company, start by familiarizing yourself with the work culture. It may all seem totally broken or incorrect at first. Before you decide to throw a thousand ideas, verify how the current approach works.
For the team, a new person who starts by pointing out errors in processes will certainly be beneficial. I’m just kidding. Rather, you will immediately have a negative opinion of your work rather than appreciate the changes. It will be best if you start by gaining allies in the upcoming changes (the ones you want to propose).
Let your new team see how you work first. Don’t they use TDD? Don’t know anything about pair programming? This is an excellent opportunity for you to show how you approach the job when carrying out a task.
Another name for this can be the low-hanging fruits method. This is an excellent reference to the idea we want to apply. Instead of starting with significant changes, the effects of which will only be visible after a long time, it is better to start with something small and simple. It is best if it is noticeable and, at the same time, as simple as possible to achieve.
Most often, teams and companies are afraid of significant changes. Change is associated with something unpredictable and challenging. It also threatens losses or problems, which nobody likes. There is a reason why projects often strive for the status quo. Fear of change and the unknown leads to surprising decisions. Also, if there is a risk of a business collapse.
Thanks to simple changes, your position in the company will improve. You will become a reliable person whose views are important in discussions. Thanks to this, it will be easier for you to push through the necessary changes (hopefully not only for you).
Don’t be afraid to work in a mess and with a legacy code. Most of the codebases you will likely come across are practically legacy code. It has evolved over and over again based on ever-changing requirements. It is often very poorly tested. You will be more productive if you learn to navigate quickly in such a repository.
You don’t need to understand everything right away. You must know how to verify the error, reproduce and fix it. Get comfortable with this mess and find ways to sort it out gradually.
Each project is different
One last thing for today. Remember that each project is different. What worked for a previous project or company may not be so perfect this time.
As programmers, we often tend to duplicate the templates we have learned. For code, this can work - patterns and principles are needed and valuable. However, when working with people, it may not be all that easy.
Wait before you start pointing out that something needs to be changed because you have worked well somewhere before. Start by making sure the team hasn’t tested it already.
Understand the hidden hierarchies in your team and company. Sometimes it has nothing to do with official job titles at all. It may be subject knowledge, internship, or the ability to build your position.
Before making changes, get to know yourself from the best side. Understand all hidden hierarchies between employees. Try to get allies to help you make changes.
You will spend most of your time with quite complex code that has gone through a lot. Try to understand it as quickly as possible, at least in general terms.
Every change is hard. However, it is worth having solid support, so before you start, make sure it’s worth it. Be fair to the team by trying to understand their work so far instead of pointing out mistakes at every step.