Learning A Codebase - What I Learned After 4+ Years At Meta
Learning a massive codebase can be daunting. Depending on the company you’re joining, the codebase might have been developed with 1000s of engineering hours and millions of lines of code. It’s literally impossible for a human to understand the whole codebase within a few years, and forget about a few months.
And yet, as the new engineer, you’re expected to become productive within a few months. I’ve found that most managers expect engineers to start writing meaningful code within 3 months (and here’s some data from the HR community with a similar time).
I spent most of my career working in companies with mature codebases: Pinterest for 2.5 years and Meta for 4.5 years. During that time, I've learned a lot about effective strategies for navigating and understanding complex codebases. Here are some key insights:
Taro
Avoid Inefficient Learning Tactics
I’ll start by sharing my mistakes when learning a codebase early in my career. These are particularly dangerous because you can “feel” productive but not actually achieve anything despite the hours you spend.
- Excessive Reading: Reading code can be helpful, but your goal should be “hands on keyboard” as quickly as possible (as we’ll talk about soon!). Reading code is an ineffective way to learn.
- Overreliance on Documentation: Reading documentation is even worse than reading code. Documentation often lags behind code changes, especially in high-growth environments. Start with documentation just to get the lay of the land, but then you need to actually open up the code editor.
Recognizing and preventing these mistakes is important so you don’t get labeled a poor performer:
Effective Strategies for Learning a Codebase
Now let’s get into the tactics. This is what helped me ramp up on codebases of various languages at Meta: Python, Java, JavaScript, C++. The tactics should apply to any language and company size, although you’ll of course need to figure out the environment setup.
- Hands-On Approach: This is the most important point from this entire article. You need to embrace the discomfort of getting your hands in the code and do something. Start coding, break things, and experiment.
- Debugging and Logging: Use debugging tools and add print statements to understand code behavior. Be generous with adding log statements -- anything from the classic “HERE” to printing out the value of a variable.
- Pair Programming: Collaborate with experienced colleagues to learn from their insights and problem-solving techniques.
This can also be done in remote work environments.
Identifying the Critical 20%
In a large codebase, the code will follow the Pareto Principle (the 80/20 rule): 20% of the components account for 80% of the impact. So your goal as the engineer is to spend most of your time on the 20% of code that matters to the business and matters to your coworkers. Here’s how you do that:
- Consult Experts: Talk to your manager and colleagues to identify the most important areas. You can look at what commits and comments various people have left in the code.
- Analyze Code History: Use tools like git blame to find frequently modified or problematic areas.
- Monitor Alerts and Reviews: Pay attention to code review comments and production alerts.
Building Confidence Through Small Wins
A promising sign for a new employee is if they can land a quick win, no matter how small. This means you want to avoid ambiguous or complex projects when you’re first getting familiar with a codebase.
- Master the Release Process: Familiarize yourself with the entire code release process, from branching to deployment. Make a dummy commit, e.g. a spelling change or unit test modification, just to see how to commit and release code.
- Contribute to Documentation: Improve documentation by adding screenshots, tutorials, and best practices. One easy way to have impact is to improve wikis by adding screenshots: e.g. a screenshot or video of the setup flow
By following these strategies, you’ll ramp up much faster than I did :) Complex codebases can be scary, but you need to act urgently to become a valuable contributor to your team, especially when you’re new.
If you’re the new engineer in a team or company, the codebase is just one area you need to spend time on. I put a bunch more thoughts into onboarding best practices in a guide here.
Best of luck as the n00b!
Rahul
Rahul Pandey
Comments ()