Excerpt from Forge Your Future with Open Source by VM (Vicky) Brasseur, Copyright © 2018 The Pragmatic Programmers LLC. Reproduced with the permission of the publisher.
Even new programmers can provide a lot of value with their code reviews. You don't have to be a Rockstar Ninja 10x Unicorn Diva programmer with years and years of experience to have valuable insights. In fact, you don't even have to be a programmer at all. You just have to be knowledgable enough to spot patterns. While you won't be able to do a complete review without programming knowledge, you may still spot things that could use some work or clarification.
If you're not a Rockstar Ninja 10x Unicorn Diva programmer, not only is your code review feedback still valuable, but you can also learn a great deal in the process: Code layout, programming style, domain knowledge, best practices, neat little programming tricks you'd not have seen otherwise, and sometimes antipatterns (or "how not to do things"). So don't let the fact that you're unfamiliar with the code, the project, or the language hold you back from reviewing code contributions. Give it a go and see what there is to learn and discover.
"But," you may wail, "how is that even possible?! I don't know how to program very well! How could I ever do anything valuable on a code review?" Calm yourself, friend. You have a lot to offer here. Earlier I mentioned pattern-spotting, and that's a good place to start. If the contribution you're reviewing looks a lot more complicated than everything around it, you've just spotted a potential problem. Does the code use different indentations or variable naming than elsewhere in the file? That's another potential problem. Is the code contribution really long, when everything else in the file is much shorter? That could be a sign something is wrong. You don't have to be that Rockstar Ninja 10x Unicorn Diva programmer to spot these things; you only have to be familiar with programming and—most importantly—you only have to be looking at the code.
Do be careful as you start code review for a project with which you're not very familiar. Some projects would rather not receive reviews from people who aren't yet skilled in the code in question, as those reviews often can contain errors or inconsistencies with how the project typically operates. Inexperienced reviewers also can confuse inexperienced contributors, who might not know that the person providing feedback to them is not very familiar with the code or the project. Always check the
CONTRIBUTING file or ask a core contributor before you start reviewing code contributions, rather than risk stepping on toes or providing feedback when none is wanted.