4 tips when joining a product with a bad codebase
Tags: career, programming, motivation, codequality
Published: 2022-01-27 19:43:38

So here it is. Your first day in a new company.

You go through the onboarding, meet your wonderful new colleagues, and you are welcomed warmly.
It is a smooth sail until you clone the new repository and see that something is not right

Actually, a lot is not right.

<p align="center">
  <img src="https://media3.giphy.com/media/xL7PDV9frcudO/giphy.gif?cid=790b7611b226b34d07acb2e680d21f9090dceb05f3c2b0d3&rid=giphy.gif&ct=g" />
</p>

Don't panic it is not that unusual scenario.

Let's discuss some tips on how to proceed

## 1. Observe

No matter how bad the code is, no matter how senior you are at all costs keep your thoughts to yourself. Don't come into the new company like a bull in a China shop suggesting changes and criticizing existing code on day one. You need a plan.

Usually, newcomers are given a few days to get familiar with all the new stuff and nobody expects any significant output from you
Use that fact to your advantage and take time to take notes of everything you _think_ is problematic.

---

## 2. Understand why

In most cases, there is a valid reason why the code is written the way it is and it is crucial for you to understand.
In my experience, they fall into the following categories:

### Lack of knowledge/ experience

This usually happens in more "juniorish" teams. It is the easiest to fight against if you are experienced enough.

### Lack of time

This can be more complicated as the problem might not be inside the time but higher up the company chain. If management is pushing engineers into delivering features as quickly as possible you might be up for a tough battle. If on the other hand the team is understaffed your arrival might solve that

### Lack of ownership/indifference

I'm not going to lie, this is bad. Nobody cares about the code quality or potential bugs and pull requests are merged minutes after opening.

Don't send your notice letter just yet. As you progress through points 3 and 4 you may ignite the new spark in the souls of your teammates

### Part of code is PoC

The team is well aware that some parts of code suck but for a good reason it stays in production. Maybe it is a new alpha feature that is waiting for an evaluation from product & marketing. If that is the case you can cross some lines from your notes.

---

## 3. Establish credibility

You are a few weeks (days if you are lucky) in and you should know the answer to _Why?_.

It's time to put in some hard work and gain street cred.
You are given tasks and features to develop. Develop them as quickly as possible while also raising the bar of code quality. Always accomplish what you commit and if possible help others.
Actively participate in code reviews and do basically everything you would want the processes to be in your ideal world.
Like they said the first three years have a greater impact on the forming of newborns' life than the rest of their life.
It's the same when you join a new company

---

## 4. Bring solutions

Now it is your time to shine.
Talk to your colleagues about the state of things as you genuinely think the team needs it. Frame it in a most unoffensive and professional way maybe even prepare PR with proof of concept of the most critical problem. Be prepared to discuss and evaluate all inputs. The goal is to make more people aware of why "it's bad" and the things that those cause.
If everything goes well this start to improve and in a few months you will have a solid codebase

---

## Conclusion

Joining a company with a codebase of low quality is challenging. Most of the time is a very hard battle. Some battles are lost and maybe at some point, you will have to leave the company for your own mental health. But when you win that battle it's one of the most satisfying feelings there is. I hope that this article will help you succeed