How do you effectively review code?

Not a dumb question at all - I actually think it's a great one!

A code review course is sorely missing from the Taro platform, and it's something that's been on my backlog for way too long. In the meantime, we have a couple resources:

• [Masterclass] How To Do Amazing Code Review
• "How to give better code reviews without full business context?"

There's a lot of information in those 2 resources, but the 2 big things that work for me in code review are:

1. Envision how you would write the same thing - From there, figure out the delta between what they did and what you would have done. Is the difference reasonable? Is their version better? Is yours? Are they both good for different reasons?
2. Pattern recognize from rejections - Look at how the most respected people on your team reject pull requests. Given that you're at Amazon, I assume this will be a collection of SDE 3s (L6s) and very tenured SDE 2s (L5s). See the common reasons they throw out for rejections and the underlying system design principles they are championing for them. From there, do the exact same thing when you see similar issues in pull requests.

When I look at the types of feedback I get on my own code, it's a mixed bag - some people leave comments on how we should handle exceptions, other ask about why we use certain libraries instead of others. There's a whole range of comment types that focus on a variety of different things from different people.

I would say that those are fair questions.

The one about library choice and have long lasting impacts as the library gets more and more ingrained in the code base. For example, choosing a graphing library or a table library could have huge implications in the future esp. if you discover incompatibility/performance issues a few months later and have to migrate all of the existing functionality over to another library.

For exception handling, you do want a consistent way of handling errors, but there should be a standard way of doing this in your codebase. If there's confusion over this, it might be worth it to take time to find out why there's contention about it because as the team grows, other people will handle it in different ways/there will be contention over the best way to handle it.

What would you recommend I read, watch or learn to do this better so I can help my team? How do you generally look at code? Are there areas or parts of it you focus on?

I would take a different approach for code reviews for feature work and bug fixes.

For feature work, there's usually a product spec/technical spec associated with it, so I try to make sure the feature work aligns to the broader spec.

For bug fixes, I would try to figure out how the bug was introduced in the first place and whether the fix actually fixes the bug, doesn't cause any unintended side effects, and doesn't violate any existing patterns in the codebase. Sometimes there can be a quick fix for a bug, but it's not the right fix. For the quick fixes, make sure there's an issue filed for following it up with the proper fix.

Of course, in both cases, you want to make sure the code doesn't have any bugs, so you do have to make sure to go line by line and make sure there isn't anything that the author might have overlooked.

If you're seeing a lot of "style" issues with code, I would make sure to invest in a good linter to automate the process so it can automatically call out any style violations.