Code Review Tips for Junior Developers

Why you should review code & how to get started

Nathaniel Morihara
Jul 18, 2020 · 5 min read
Image for post
Image for post
Murphy reviews code. Be like Murphy.

Why review code?

  • It gives me practice reading code.
  • I learn more about the code base.
  • I learn different styles and approaches to writing code.
  • I understand what people are working on and what is changing.
  • It helps my teammates improve their code, catch bugs, and get their code through the door.
  • It earns respect from teammates.

Hopefully, you’re convinced you should make code review a habit. However, the biggest hurdle probably isn’t motivation, but uncertainty on how to get started.

Tips for reviewing code

Here are a few things you can do when reviewing even the most unfamiliar code:

  • Ask what the code is doing. Take the time to understand the code and read it line-by-line. If you come across something you don’t understand, look it up or sift through README’s and any other documentation. There may be no such thing as a “bad question”, but there are lazy ones. If you still don’t understand something after doing your due diligence, ask the code author if she can explain the line(s).
  • Ask why the code is written the way it is. You might understand what is happening, but why is it implemented that way? Why is the variable/function named that way? Why is that a list rather than a set? Does it make sense? Is there a better way? Writing code requires a lot of decisions and it’s easy for the author to overlook small things while he’s focusing on getting the code to work. An extra set of eyes asking “why?” can help the author identify things they’ve missed.
  • Ask that a pull request be kept small. If you’re glancing through the files comprising the pull request and thinking to yourself, “Do I have to look through all this?” then there’s a good chance that the pull request is “too big”. You aren’t being lazy: large pull requests are bad not only because they’re a pain to review, but also because they are inherently riskier. While there may be a good explanation as to why the pull request is so big, it is best for everyone if you at least ask if a pull request can be broken down.
  • Ask for a good commit message. Not just for your sake, but future generations (including the author himself!). It’s easy to forget why even your own code was changed, let alone someone else reading your code and trying to understand it. A good commit message not only outlines what was done but why the change was made.
  • Ask for tests. Most organizations would agree that it is best to include some form of tests with (almost) every change. If you don’t see any tests in the pull request, ask if there should be (I say “ask” because there may be a good reason not to include tests). If tests are already included, you can also help out the author by making sure that the critical code paths and edge cases are tested.
  • Look for bugs at the “micro” level. Should there be a null check? Does the if-statement behave correctly for all permutations? Is there a return statement in the wrong place? Make sure the line-by-line logic makes sense. This doesn’t require a knowledge of the overarching codebase: any developer should be able to catch these types of problems. If you can spot a “micro” level problem, it probably means there’s a missing test case that could be added.
  • Look for bugs at the “macro” level. Reason whether or not the change to application logic may have unexpected consequences. These types of problems require high-level reasoning and are often harder to spot. Examples might include: Should we be removing the message once it’s been read? Does changing this name break a pointer in some other part of the application?
  • Read “Clean Code”. It outlines best practices for writing maintainable code. Most of the comments in my code reviews derive from ideas in this book, and I highly recommend it to anyone who works in code. If you or your teammates disagree with the paradigms it suggests, find your own philosophy. Either way, I think it’s important for you and your team to be opinionated and aligned on what makes for clean, maintainable code, and you can help enforce it through reviews.
  • Practice good etiquette. Reviewing someone’s work is a personal process, and criticism (constructive or not) can be difficult to digest. Help the author out by softening your request/comment, whether it’s a fact or opinion. A few strategies for doing this:
    1. Frame suggestions as questions. “Maybe it would be better if…”, “What if this was done this way…”, “Do you think it might be better if…”.
    2. Keep it impersonal. Don’t say, “I think you did this wrong” or, “You could’ve done this better by…”. Instead, say, “I’m not sure this is correct” or, “I think this could be better”. Generally, leave out the word “you”.
    3. Only block a pull request if you think there will be a bug. Don’t block pull requests because of an opinion.
    4. Be polite. We’re all busy adults, but “please” and “thank you” still go a long way. Whether you’re reviewing code, or asking for a review, being appreciative for someone else’s time and effort is always a good idea.


Asking questions is my go-to when reviewing unfamiliar code. Not only does it help me learn, but it forces the code owner to think critically about her code, which may lead to new insights or bug fixes.

Happy reviewing!

The Startup

Medium's largest active publication, followed by +771K people. Follow to join our community.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store