Name: Code Review MUST Be Fast, Otherwise The Team Is Unhealthy
Uploaded: 2022-04-14T04:54:31+00:00
Duration: 4 min 10 s
Description: In the end, code review is a gatekeeper, so it has to be fast for the team to ship quickly

Code Review MUST Be Fast, Otherwise The Team Is Unhealthy

- In the end, code review is a gatekeeper, so it has to be fast for the team to ship quickly.
  - This is especially true if you work for a high-performance tech company like FAANG or a hyper-growth startup.
- *If you're evaluating a team, definitely ask about what its code review culture and speed are like.* Not only does faster code review lead to smoother shipping, it also enables faster learning.
- It should take 1-2 days to get code review feedback, and even 2 days is pushing it.
- What's important to realize is that a lot of pull requests will take multiple iterations to be finalized. Let's say it takes your teammates 3 days to leave feedback, and you need 3 revisions before your PR is perfect. *This means that landing 1 PR took you over a week.*
- Have a focus block at the end of your day where you can review all open pull requests from your team to enable that 1 day turnaround.
- Code review is inherently a more selfless act as it unlocks someone else. *Doing lightning fast code review is an extremely powerful way to be a stellar teammate.* Alex got to most reviews within 2 hours.
- On the flip side, don't be too pushy asking teammates for code review. Wait for around a day at least before pinging them (unless it's an urgent PR).

Related resources:
- [Avoid These Junior Engineer Mistakes With Code Review](https://link.jointaro.com/agkYrLH8uuCv4UcPA)
- ["How do you suggest code review feedback where you think there’s a better way to do what they’re currently doing?](https://link.jointaro.com/y9sQNWiPqFct4ad2A)
- ["How can I write great code faster?"](https://link.jointaro.com/1h3FLBSJWxbVoEUo6)

In the end, code review is a gatekeeper, so it has to be fast for the team to ship quickly

Code review is one of the most common and powerful ways for software engineers to learn. On top of increasing code quality, it builds engineering culture within a team.

Code review can catch coding mistakes and design flaws before the code reaches production

A good code review process is needed to catch bugs, increase maintainability, and guarantee a high velocity future contributors.

Code review ensures high quality software that is maintainable for the lifetime of the code

We all have the same 24 hours in a day - The difference is that some are able to get far more out of it than others. Here's what they're doing that others aren't.

[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)