It’s not a secret that working alongside other developers makes you a better developer. Having people reviewing your code, helping you when you are stuck and seeing how others think about problems, expands your knowledge and improves your problem solving skills.
When you are working alone in a project you just rely on our beloved StackOverflow when you don’t know how to solve a specific problem. When you are the only one familiar with the codebase it’s not easy dragging someone into it to have a look and try to help, so at that point you think: “I’d kill to be working on a team that understands my problem, have the context of it and knows the codebase so they can help me with this!”
Don’t get me wrong, working alone has its perks. You follow your own rules — they might not be correct, but are yours! -, you work at your own pace and have everything under control. Working on a team can be chaotic at certain points, so many messages and brains spilling out ideas, loads of opinions and different styles of coding.
While trying to figure out what’s best is an interesting discussion, I want to focus on the challenge that transitioning from working solo to working on a team of developers means.
My name is Javi and I work at Phorest Salon Software as a software engineer, where I started as the only web developer of the company. That was not new to me, before joining Phorest, the biggest team I had since I started coding more than 10 years ago was 2 people, and that’s including myself. After more than 2 years working as the only developer on the Phorest website I transitioned to the product development team, joining a team of more than 10 developers.
The start of the transition
The theory says that the more people the better, you can share your problems and concerns and you are not alone resolving them or making difficult decisions. I agree on that now, but I must admit that I didn’t in the first weeks or even months. It takes some time to get used to receiving feedback from your code at every new feature you develop. You start feeling constantly challenged, less confident about your developer skills, getting frustrated because your code seems to always be wrong or that there’s always something to improve. Then it began, the famous Imposter Syndrome.
Up until that point I’ve never had anyone reviewing my code thoroughly so it was a bit of a shock receiving that feedback. I understood that it was a good thing and that it would help me improve my skills, but at the same time I had to deal with that feedback, adjust my code to what my teammates suggested and that meant that I was spending more time than before on a single feature.
Usually when you work alone you stick to a fixed set of coding standards of course, but you have more pressure to release features on time because the responsibility lies solely on you, so you don’t pay that much level of attention to improving the code if it works as you expect. That changes when you work in a team. Yes, you can still have pressure to deliver things within a deadline, but at the same time you’ll have to deal with changes in a code that works, for several reasons: cleanliness, quality, consistency, team standards etc.
What did I learn?
Transitioning from working alone to working on a team is not just a matter of how you are going to work and with who, but also to change your perspective regarding the code you write. You are not coding for yourself anymore, you are coding for other developers that need to understand your code, to use it, and to be comfortable with it. You are going to have more eyes on your code that will catch potential issues you overlooked. You will learn new ways of solving problems and you will realise that the approach you have always followed might have not been the best one. And more importantly, it will give you a chance to discuss that code with other engineers and that, my friend, is what makes a developer grow.
I feel like I’m in a better position now and that I can share some pieces of advice to anyone that is going to make that same change or is in the process right now:
Be mentally prepared to accept that your solution might not be the best one, and that now there’s going to be more developers that will make you think differently.
Embrace the feedback. Don’t take it as a “you did something wrong” but rather as a “this is how you could improve it”.
Coding is not an exact science and there are infinite ways of achieving the same result. If you think your code is the way to go, don’t be afraid to start a conversation to defend your choice.
Your teammates are there to help you, you want to achieve the same goal together. Don’t get frustrated if your code gets pushed back, it’s a team effort to achieve the best code possible.
Be grateful. Someone else is helping you to be a better developer, take advantage of that!
Be considerate. The code you write is not only for your way of thinking anymore, it has to be understood by others, keep it clean and as structured as possible.
Be sure that your team uses a code formatter and lint rules, so the gap between coding styles gets reduced as much as possible.
If you are on the opposite side and you are welcoming to your team a developer that is used to work alone,
Let them know that it’s ok if they need a bit of time to get to the same speed as the rest. Remember, the developer might not be used to working actively with collaborative repositories or project management.
Let them know that it’s fine to defend their ideas and not to be restrained.
Be sure to check on them on how they are doing. They might feel insecure and frustrated and could lead to self-esteem issues.
In any career, transitioning to a new way of working is always a challenge, so be mentally prepared for that, embrace the change, learn how to deal with it, stay strong with what you think it’s right and above all of that, enjoy the journey.
Top comments (0)