How to Get Up to Speed in an Unfamiliar Codebase
When you start a new job as a software engineer, whether it’s your first or 10th, one of the BEST things you can do to make an impact quickly is to get up to speed in your new codebase. Depending on the type of company you join, you may be eased into the work, or you may be thrown right in and expected to start contributing right away. Understanding how things work at your new company, both at a high level, as well as at a micro level, will help you figure out how you can make a big impact in both the short term and the long term.
Though you might not be expected to contribute code right away, it’s still important to get familiar with the new codebase you’ll be working in. Whether someone is assigning you your first project or you are in a more self-directed role, getting up to speed fast is a great way to impress your new team.
I remember the first time I started working in a real production codebase. I had just finished a 3 month teaching assistant role after completing a bootcamp and I’d only worked on codebases from my or my classmates’ projects. Even though the company I joined was small and had a relatively new codebase (< 4 years old) that was virtually free of technical debt, I was overwhelmed by the size and scale of everything. The first thing I noticed was that there were so many more files. I felt like I had no idea where to find anything and my bootcamp projects suddenly felt tiny!
I’ve since worked in a few different codebases, and each one has been vastly different from the next. Most have had technical debt in some form and I’ve had to get up to speed quickly in each one in order to start contributing.
Here are some strategies I’ve learned that you can use to get up to speed:
- Take a wide view and a detailed view
- Read the code!
- Fix bugs
- Write tests
- Pair with other engineers and ask questions
- BONUS: Hackathons
Whether you usually focus on the big picture or prefer the small details, it’s important to look at the codebase from both perspectives. If you’re stronger in one area, you may gain some new insights from looking at the code from the opposite perspective than you’re used to. When you take a wide view, you could be looking at the overall organization of a codebase or how several systems work together. When you take a detailed view, you could be trying to understand the implementation of a specific module.
Here are some questions to answer when looking at the codebase from each perspective:
- What languages and libraries/frameworks are used?
- What is the file structure?
- What are some commonly used external dependencies?
- You’ve picked a file or a module – what does this file or module do and how does it do it?
- Do you notice any coding style patterns?
- What’s your overall impression of the code quality?
One of the most important goals of taking a wide view is looking at the file structure. If you’re working in a monorepo, this could mean looking only at a specific subset of files rather than the entire repo. If you’re working in a smaller service or app, looking at everything together can be helpful.
Understanding how the codebase is structured will help you with knowing where to write or debug code. Often when starting a new job, the where can be trickier than the what or the how. If you already have a general sense of the organization and structure behind what you’re working on, you’ll have an easier time finding the files you need to edit or the right places to add new files.
For example, here’s a sample file structure for a small app I created using create-react-app:
This next suggestion might seem obvious, but it’s so important! When you’re starting a new job, actually reading through existing code is a great way to get up to speed. This can be through code reviews, or just on your own as you’re investigating a task. Reading the code will help to give you a more detailed view of what is happening in specific files and help you gain context on the area of the codebase you start working in.
Also, make sure to pass the knowledge along! For example, if you ask a question in a code review, you are now empowered to answer that question when someone else asks.
Fix bugsFixing bugs is one of the BEST ways to get up to speed in an unfamiliar codebase. Not only will it help you learn more about the product you’re working on, but you’ll also be actively helping users as you fix problems. Fixing bugs can also help you understand how something works end-to-end or how a few systems tie together.
One personal example of this was when I fixed a bug where a CSV download was incorrectly including extra data. It was a problem that had been reported for awhile, but no one had taken the time to look into it. In working on that bug, I went through the flow in the UI to understand what our users were experiencing. I then walked through the code to figure out what was actually happening. As it turned out, the bug fix was just a simple deletion of a few lines of code, but in the process of figuring that out, I learned a ton about that specific part of the product and how it was implemented.
Pair with other engineers and ask questionsAnother way to get up to speed quickly is by pairing with engineers who have been at the company for longer than you, even if by just a few months. These engineers will have more domain knowledge about specific areas of the codebase – they will be able to help give you context around why a system was built a specific way or potential “gotchas” and hacks due to technical debt.
For example, I was working on building out a new feature, and initially thought I would need to build a complex UI component from scratch. However, when I paired with my teammate, she showed me an existing component that I could leverage. This saved me time as I was able to focus on understanding the code that already existed rather than starting from scratch. Even better, I knew where to check for existing components the next time I was starting a similar project.
Write testsUnless your company is extremely strict about following Test Driven Development, there are likely to be several areas of the codebase that lack test coverage. When you come across any code that doesn’t have tests written, write some! Writing tests will help you understand how the code you’re looking at works and it will require you to think of edge cases around that code. You may even discover a bug because the code is not handling a certain edge case.
BONUS: HackathonsIf your company runs hackathons, these are a great way to learn more about a part of the codebase or relevant technology that you may not already be familiar with. In this case, it’s important to spend time up front investigating and planning so you don’t run out of time when it comes to the actual implementation of your project. During that investigation phase, you’ll likely encounter code that is unfamiliar to you. I would recommend picking projects with very limited scopes if you’re new to the codebase or hackathons in general.
For example, I worked on a hackathon project to add a different colored favicon for each environment, so when developers have many tabs open, it’s easy to identify development vs. staging vs. production. This was a case where the implementation was relatively straightforward, but finding where to write the code was more challenging. This project was a great learning experience because it helped me understand some parts of the codebase that I wouldn’t have necessarily encountered. I also learned about some quirks within our codebase that will be useful to keep in mind for future code reviews.
ConclusionSo, there you have it, my 6 tips for getting up to speed in an unfamiliar codebase. If you’re starting a new job or even changing roles or teams, hopefully these tips will help you feel comfortable and confident in the new codebase. Do you have any other tips or tricks that have worked for you? Please share them in the comments!
To read more from Jane, check out her blog, Full-Stack Interviewing.
