Name: Learning A New Codebase? Here's How To Figure Out What Matters
Uploaded: 2022-04-09T18:37:55+00:00
Duration: 3 min 43 s
Description: In this video, we explore how a strong test plan benefits not just the immediate code review process but also long-term

Learning A New Codebase? Here's How To Figure Out What Matters

In this video, we explore how a strong **test plan** benefits not just the immediate code review process but also long-term codebase understanding and team efficiency. As engineers join new teams or revisit legacy code, test plans become invaluable guides for understanding and validating past changes.

### Key Takeaways:

- **We use test plans to unlock team knowledge**: In large codebases, no one fully understands every part of the system. A clear test plan helps future engineers (and our future selves) grasp what a change does and why it was made.

- **We prioritize hotspots over ancient code**: When onboarding to a team, we focus on recent changes in active areas of the codebase—not the 1,000 untouched lines at the top. Test plans tied to recent diffs help us make sense of these hotspots quickly.

- **We support testability with repeatable artifacts**: Whether it’s a video, screenshot, or command-line script, we include a way to replicate and verify our changes. This ensures others can validate functionality easily and efficiently.

- **We aim for speed and clarity**: For front-end work, visual demos (videos or GIFs) help reviewers instantly see the impact. For backend or logic-heavy changes, unit tests and integration scripts are more scalable and maintainable.

- **We build infrastructure for long-term velocity**: Investing early in test infrastructure—like command-line test runners—makes it easier to validate changes quickly and helps teams move faster as the codebase grows.

Ultimately, we think of test plans not just as review aids, but as **living documentation** and a **key onboarding tool** for future engineers working in our code.

In this video, we explore how a strong test plan benefits not just the immediate code review process but also long-term 

[Masterclass] How To Do Amazing Code Review

Code review is one of the most effective ways to learn as a software engineer, especially for those earlier-in-career. Unfortunately, way too many engineering teams get it wrong with slow review speed and low quality comments.

There is a mountain of information in this presentation, so here's our 5 favorite points (in no particular order):
- **Code review is NOT for catching bugs** - Of course, if you find a bug in a PR (pull request), you should call it out, but that's not the primary purpose of code review. The core benefit of code review is to build up engineering culture, propagating best practices amongst the team and growing newer and more junior engineers.
- **Add deep context to your PRs** - Explain what your pull request does and the reasoning behind your approach. Also, *include a test plan.* A test plan is a demo showcasing what your code changes do; try to make it a video/gif, which is especially powerful if you work on front-end (Android/iOS/web). If you can't do a video, try attaching a screenshot or a set of commands to run tests.
- **One diff, one thesis** - Every PR should be focused and atomic: Don't jam the entire new feature you just coded up in a single 1,000+ line PR. Huge commits are hard to review, and your teammates will hate you for it. For the vast majority of cases, you can break down your PRs to 25-250 lines of code.
- **Read others' code reviews** - Similar to so many other things in tech, stand on the shoulders of giants where you can. With code review, this means looking at how senior+ engineers on your team comment on reviews. Try to find patterns in the issues they're finding and incorporate it into how you review code. Revisions that have been rejected with changes requested are a gold mine for this learning.
- **Code review MUST be fast** - When we say fast, we mean that feedback should arrive in <24 hours. What a lot of engineers don't realize is that code review delay is multiplicative: Sometimes commit will need 3-5 revisions before they're able to be merged. If turnaround is 2+ days, this can easily lead to commits taking weeks to land, which is far too slow.

A lot of the terminology in this video is Meta specific. If you're more used to GitHub:
- Diff review = Pull request
- Diff = Commit

Related resources:
- ["How to give better code reviews without full business context?"](https://www.jointaro.com/question/vio35mw1SYWM8AYojB2w/how-to-give-better-code-reviews-without-full-business-context/)
- ["How to review code in another language/ from another team?"](https://www.jointaro.com/question/B79W3aWc8xMB8cCULFdJ/how-to-review-code-in-another-language-from-another-team/)
- [Presentation Slides](https://docs.google.com/presentation/d/1koyIR9K_CtESD7Vnh3GQOE-svFW-ngrQeEAduSAoH0w/edit)