Joining a New Team: How to Avoid Breaking Code, Processes, and Spirits

Walking into a new engineering team feels a bit like being the new kid at school—except instead of worrying about where to sit at lunch, you’re trying to figure out how to deploy without breaking production. There’s an urgency to become productive as quickly as possible and prove your worth—especially if you’re a junior developer surrounded by experienced seniors.

Most companies provide structured onboarding for new engineers, but that usually covers how to access the codebase, the overall coding standards, company culture, and processes. What you don’t always get is direction on how your team actually works or the historical context behind the codebase. If you’re joining a startup or an early-stage growth company, you might find yourself thrown into the deep end with little guidance. In these situations, understanding both your team’s dynamics and your development environment becomes crucial.

Building Rapport with Your Team (a.k.a. Don’t Be That Guy)

Building a good rapport with your team is always valuable. In small teams, hiring is usually intentional—there are gaps in the team’s strengths, and new hires are brought in to fill them. That puts you in a good position. The team hired you because they thought you’d fit in. One of your top priorities should be figuring out which of your strengths are most urgently needed.

Your probation period is when your team is essentially evaluating whether you can do all the wonderful things you claimed in your interview. This is the time to focus on your core strengths and prove your value. Nobody expects you to fix everything in your first few months—but they do expect you to be useful.

Once you start getting comfortable, you’ll inevitably run into legacy code. And let me tell you—it will test your patience.

Legacy Code: A Treasure Chest or a Landmine?

If you’ve had the fortune of dealing with legacy code (and I do say fortune, because it gives you a front-row seat to your codebase’s version of the Big Bang), approach it with a mix of gratitude and caution.

If you come across well-structured code, be grateful—maybe even treat yourself on the way home. If you stumble upon code that makes you question the sanity of its author, don’t just assume they were having a bad day. Instead, find out why it was written that way. Talk to your colleagues—someone likely knows the backstory.

Your predecessors may have been hacking away at 1:00 AM on a Sunday, desperately trying to get something working for a Monday morning demo. They probably meant to clean it up later but never got the chance before they burned out and left. Empathy goes a long way. And if you think that code is bad, just wait until you see the code that works, and no one knows why.

That Ugly Code? Maybe Leave It Alone

One of the biggest mistakes I made early in my career was seeing messy code and immediately wanting to refactor it. Bad idea. If you find code that looks like an abomination, proceed with caution. If there are no unit tests, do not touch it unless you’re adding some—and even then, tread carefully.

The last thing you want is to introduce a bug and break something in production. (Backend engineers have the luxury of rolling things back quickly, but frontend and mobile engineers… good luck explaining that to your users.)

If you’re eager to contribute as soon as possible, remember: not wasting your team’s time fixing the bugs you introduced is an even higher priority.

How to Fix Things Without Becoming the Office Villain

It’s understandable—you have prior experience, and some of your new team’s processes might seem outdated or inefficient. The same goes for coding practices. At my current company, our Android team has a ritual where new teammates are encouraged to note down inefficiencies or suggest improvements before they get too accustomed to our ways of working. This helps us evolve while making fresh perspectives count.

But if your team doesn’t have a system like this, take it slow. Before suggesting big changes, give your team time to trust you and your work. Once they trust your judgment, they’ll be more open to your ideas.

(Of course, if you’ve been hired specifically to shake things up, this doesn’t apply. Also, none of this applies to Elon Musk—he does what he wants. 😛)

TL;DR

1. Understand the codebase and its history. Before judging questionable code, find out why it exists. The developer before you may have been in survival mode, just trying to meet a deadline. Empathy goes a long way.
2. Suggest changes thoughtfully. Efficiency improvements are great, but let your team trust you first before you start refactoring half the codebase.
3. Ease into your team’s workflow. Prove your value first before trying to change things. Build trust, ask questions, and choose your battles wisely.

PS: ChatGPT may have helped me with this.