Introduction

Since getting into the tech industry, we probably have asked the questions "What does it look like to join an existing development team", "What it feels like in the real world", or were even scared of legacy code and asked "What to do if my job was to maintain legacy code". Thankfully, I did not get into maintaining legacy code! I, however, was integrated into an existing codebase. After joining the company, in one of our meetings, I've also asked the question "What's harder, to integrate to an existing codebase, or to start from the ground up?" Got mixed opinions. The project that we were integrated into was the former. And after the experience, I finally have an opinion on it.

The First Expedition - Delving into Documentation

After we have been added to the project and were given access to the GitHub repository to study the codebase. And what's the first thing you'll see? A bunch of nonsense, words that don't make sense, directories that lead to more directories (especially if it's a monorepo, and it's exactly what we're using).

It was overwhelming, the project we were in was arguably a large one. This is fine, this is completely normal, so, what's the reasonable thing to do? Ask. Ask someone more senior, ask whoever came before you. Ask where to start and so on. Well, most likely than not, they'll refer you to the documentation. Which is not a bad thing, because at the very least, knowing this will give you some sort of assurance. But it definitely did contain all the things we will need to know about.

Since we were working on the frontend, we only needed to focus on a few specific directories. Thank God. Great, so I've started reading the documentation or the README file at the root of the project. Depending on the organization, how to set things up, configurations, conventions, and so on, should be well documented there. A Table of Contents is especially helpful. If you do not see any of this sort, then it could be an opportunity to contribute one, be proactive even if you're the new junior! It provides a great overview of the scope of the project and what you should expect. Definitely a must have. Carefully read through it, do not dive into the codebase and look through the files yet. Ask questions for the things you don't understand, you might even find an issue in the documentation, It's another contribution! I personally didn't get those opportunities, because they were already well written, but you might!

The next thing is, find the CONTRIBUTING guide. Every team has a standard. Ways to write commits, pull requests, branch names, code review process, etc. This part will be a bit easier to read. 9 out of 10 times, you'll probably still mess some things up especially with Git, BUT! Don't worry about it, no one will be mad at you (hopefully!). If you are unsure of something, always ask clarifying questions. Don't be afraid to ask questions, because I definitely didn't I don't want to get things wrong.

Unraveling mysteries through detective work

We've finally started, it was time to pick up tickets to work on. But seeing the board, you're overwhelmed with a tsunami of tasks again! So like always, what's the most responsible thing to do? Ask again! Someone will be more knowledgeable with the tickets, they'll know which ticket is best suited for you. This is not a bad thing, ask someone to help you pick your first ticket, ask what's going to be the process. I definitely did, my first ticket wasn't that huge, it was literally capitalizing a word, changing ONE letter. But it was my proudest moment nonetheless, that I've finally got my feet on the codebase and left a mark, it was the initial connection.

After taking more tickets, writing more code, I felt like I still didn't learn the codebase very much. However what actually did, is doing code reviews. This is an intentional process, you might ask, why not just read the codebase directly maybe in your IDE/text editor, it's the same, no? Sure, but personally that didn't work for me, it felt like it wasn't as intentional. It didn't particularly feel like it had a purpose, that I really wanted to understand this code, but I wasn't able to.

Being assigned to do a code review means that they expect something from me, they've assigned me because I've probably touched the code last and so I have some authority and knowledge to know the behavior within that domain of the code, and that there's some level of responsibility and ownership.

You of course don't need to be assigned as a reviewer to do a code review. It's equally as valuable, because you are trying to understand someone else's code. It's easier to test because you absolutely know where to start from based on their code changes, the changes are visible to you, you know what ticket they are referring to. You have all the necessary context here. The concept of deliberate and structured evaluation of code transforms the way one comprehends code. Unlike passive code inspection within your IDE/text editor without a single clue where to start or what the context is, a code review is driven by intentionality, focused on grasping the intricacies and improvement of one's understanding.

As a principle we have in GFED:

The goal of code review is to ensure we are shipping quality software and as a team, we have collective ownership of the codebase to ensure this happens, but a secondary goal of code review is for us to get familiar with the code and knowledge share, potentially ask questions if something is not clear or can be done better.

It resonated a lot with me, and yes it did greatly help in familiarizing myself with the code base. Not only that, you are also learning from other people's code. Both the reviewer and the reviewee both learn from each other. Asking questions on their thought process was super helpful as well. Understanding someone else's code means you need to understand their thought process, how they got to that conclusion, what made them do this and that, what were the steps they've taken to accomplish this and that, and so on.

So when trying to learn a codebase no matter how large it is, do code reviews, assigned as a reviewer or not.

Embracing curiosity and questions

Notice that in each section that I've asked some questions or even influence you to ask questions. I've definitely asked a lot of questions, be it the people in the project or in the company. I definitely appreciate everyone. The important thing in the workplace is to never get stuck, there are people that can help you.

"The man who asks a question is a fool for a minute, the man who does not ask is a fool for life." ― Confucius

I've also seen a lot of people getting stuck for days on a problem, and I've always asked them, why didn't they just ask for help? There were multiple answers that I saw:

1. They are afraid to ask questions because their questions might be considered "dumb" or "obvious".

2. They feel like they won't learn anything if they ask for help, that they must do it themselves.

3. They think they understand the topic pretty well so why ask for help?

4. And a lot more reasons.

These should not be reasons to not ask a question. Do not ever limit yourself. However, there are things you definitely need to understand. If two people asked for help on the same problem. Person A asked with little to no context at all and nothing else, Person B asked and shared the context of the problem, shared the steps to reproduce the problem, shared some code, and shared the things they've tried already.

It's obvious that 100% of the time Person B will receive help. But don't worry Person A will also receive some help, well to start, kindly ask them to do the same thing as Person B. The main takeaway here is that Person B showed that they **wanted** to improve, that they tried things themselves, researched before asking the question and so on, while Person A looked like they just wanted to rely on someone else.

Asking questions is super important not just on the job, but pretty much on your daily life. You need to have the willingness to ask questions. It's an invitation to improve yourself and set yourself up for success in the workplace. Having context will greatly help the person trying to help you, and see that you've actually put some effort into the question.

Let us be your rubber ducks, I've also seen a lot of people when writing their questions, they suddenly figure it out on their own, so it's actually super effective.

As a basic template, use this when asking a technical question:

1. What is the problem? How did it come up?

2. Where is the problem located? Where are you experiencing the problem? Is it identifiable somewhere?

3. Can other people, especially the person you're asking for help replicate it as well?

4. What do you expect to happen? What do you think should be the final result?

5. What have you tried? What have you researched about the problem?

Conclusion

Jumping into an existing codebase might feel like diving into the deep end, but guess what? You've got this! As you've previously seen, thorough documentation, diligent code reviews, and proactive question-asking form the pillars of a successful onboarding process.

Utilizing the collaborative nature of code reviews and not hesitating to seek clarity through questions will not only aid in your personal development but also strengthen the team as a whole. Your inquiries will often shine a light on aspects others might not have considered.

So, stand tall in the face of complexity, and remember that the journey you've embarked upon is not only about code but about your evolution as a developer.