What do you look at during a code review?
Hey everyone,
I'm a mid-level engineer on a team where most of the others are seniors. I need to start reviewing their code, and I’m not sure what I should be focusing on.
When you do a code review, what exactly do you look for? Is it more about the code style—like variable names, function length, clarity—or should I also be evaluating technical decisions, like whether the overall approach makes sense?
It’s especially tricky because I’m still relatively new to the team, so I don’t have full context on a lot of the files or systems yet. I’ve seen advice about how to write code that’s easy to review, but less about how to perform a good review, especially when reviewing someone more experienced than you.
Would really appreciate hearing how others approach this!
Discussion
(2 comments)- 2a month agoTech Lead/Manager at Meta, Pinterest, Kosei
We have a whole master class about code review! https://www.jointaro.com/lesson/rhRFh49oouaUDhWUvkQb/masterclass-how-to-do-amazing-code-review/
The ultimate code review is to actually patch the diff onto your local machine and test it out or think about how you might have written the code differently. Of course, this is prohibitive in terms of time for every code change, but I would recommend doing it initially to get a sense of the project or code.
There is definitely an element of code style, or idiomatic language use in code review, but I find that the best code reviews are about anticipating what might go wrong based on the future direction of the project or future.
- 2
a month agoCoaching Managers & Senior ICs | Ex-Meta, AmazonWear hats. That's the secret to reviewing code.
The mistake that new engineers make is that they just read the code and throw on comments. Don't do that. Have a plan and a structure to how you review code.
When you read the code, wear a single hat at a time. Every hat is a single question that you bring into the review. Like the hacker's black hat of how to exploit the code.
Here are some other "hats" or questions:
- Does the code do what it says it does?
- Will this code be easy to maintain in a year? (Readability, single-responsibility, testability, etc.)
- If I wanted to break the code, how would I do it? (Edge cases, scalability, poison pills, etc.)
There are other angles, such as privacy, security, integrity, etc. But these are the basics.
Pick one hat, do a pass.
Then pick another hat and repeat.
Related Course
