For new developers, writing code reviews is one of the more intimidating tasks. You’re expected to catch mistakes and leave meaningful feedback on the work of developers with more experience than you. It’s easy to assume you have nothing to contribute. That’s not the case, and moreover, it’s important to collaborate with your colleagues. So how do you get started? I’ve been a working software developer for four years, so while I’m not exactly new at it, I was quite recently, and I remember this particular stress. This September, when I joined a new project after an extended maternity leave, I dealt with some of these same concerns. Luckily, I’ve picked up some tricks since my newbie days. Here are my personal tips to get started contributing to code reviews.
1. Start by spying on code reviews.
Congrats on the new job! A big part of your onboarding will be getting familiar with the code. One great way to do this is to ‘shadow’ code reviews. As your team posts PR links, just take a look at them. No one expects you to do reviews on your first day (or week). See what kind of comments your colleagues leave for each other. Get familiar with how your team interacts with one another. Of course, you can and should bring your own unique perspective to the team. But it’s good to get acclimated to your team’s review culture. Do they adhere to strict naming conventions? Do teammates like to ask questions and do a lot of knowledge sharing in reviews? Peeking at pull requests will also let you see what kind of work is being done, giving you an up-to-date snapshot of the parts of the codebase you’re likely to work on soon.
2. Get some context before diving in.
Your colleague posted a PR link. Awesome. Don’t just click on it and start reading. Make sure you understand the context first. What is this code meant to be doing? If your team uses Jira, read the Jira ticket. Take a look at the application and make sure you understand the desired outcome. Ready? Great. Let’s take a look at the code.
3. Pull down the code and run it.
You won’t always need to run the code you’re reviewing. But for a developer looking for a way to contribute, this is a useful step. It will easily show you what the code does and how it looks in action. This is especially useful for front end code. Test the app like a user would – can you break it? Are edge cases caught? For front end code: does it look right?
4. Read the code.
Of course, you’re going to have to read the code. Try your best to understand it and ask questions if you have them. Look for these specific things: functionality (does it do what it’s supposed to do?), readability (is it easy to understand? should comments be added or names clarified?), performance (is there a more straightforward or performant way to achieve the same result?), adherence to coding standards, and test coverage.
5. Some final suggestions.
Be specific, be respectful, and avoid nitpicking. This is someone’s hard work you’re reviewing. You want to leave constructive feedback while also respecting their choices when they might do small things differently than you.
Don't underestimate what you bring to code reviews, even as the new dev on the block. Fresh eyes often catch things veterans have stopped seeing - like confusing variable names or missing test cases. These steps aren't just about ticking boxes - they're your roadmap to becoming the kind of reviewer you'd want reviewing your own code. Start small, ask questions when you're stuck, and remember that every senior developer started exactly where you are. Code reviews get easier with practice, and trust me, your team needs your perspective just as much as you need theirs.