# Code reviews

Code reviews don’t need to be – nor *should* they be – only about finding bugs and errors. They give us the opportunity to improve the quality of our codebase by providing feedback that helps move the code forward. Sure, that could be a fresh set of eyes catching a typo... but it’s also about learning new things, asking questions and talking through decisions, and giving praise when you see awesome code!

Our codebase is a team effort and it’s important to remember that we’re reviewing code, not each other. When you’ve spent hours/days working on a piece of code, sometimes it can be easy to take feedback personally. As reviewers, we can minimize the risk of misinterpretation (as well as provide better, more constructive feedback) by keeping a few points in mind:

* [Frame feedback as requests rather than commands](https://mtlynch.io/human-code-reviews-1/#frame-feedback-as-requests-not-commands)
* [Don’t use the word “you”](https://mtlynch.io/human-code-reviews-1/#never-say-you), and use the passive voice in your feedback
* When requesting a change, also [note why you are making the request](https://mtlynch.io/human-code-reviews-1/#tie-notes-to-principles-not-opinions), and perhaps even [provide an example](https://mtlynch.io/human-code-reviews-1/#be-generous-with-code-examples)
* Remember that you can also use comments to ask questions or start conversations

For a deeper dive, we **highly** recommend reading *How to Do Code Reviews Like a Human* ([Part 1](https://mtlynch.io/human-code-reviews-1/), [Part 2](https://mtlynch.io/human-code-reviews-2/)). Many of us have found it quite valuable!