Josh Kersting

I've recently found myself in the position of having to review code I didn't understand. It was intimidating. It made me wonder "what do I have to offer here?". Not only was I unfamiliar with the language the domain was an area I had little experience.

Code reviews are generally thought of as a way to learn by having others review the code you've written. They're a good way to get feedback on the patterns and tools you've used. They also allow one last chance for an extra set of eyes to catch any bugs. More importantly, I've learned, they're a great way to learn from the code others have written.

How does that help me when I don't know the language or domain?

I started by asking what I did know about the code. Luckily most languages share a lot of syntax and features. I couldn't tell exactly what was happening. I could figure out generally what was going on. That was a place to start. I asked broad questions about the changes to test my understanding.

It looks like we're doing X, does that sound correct?

Once I was confident I knew generally what was going on I could address the pieces that I didn't understand. In some cases looking at the language or library docs was enough. In others I had to ask the developer.

What is this function doing?

What's the difference between this code here and that code?

Over time with enough PR's and slack messages I was able to grow my understanding from not knowing what was going on, to being able to write and review.

Summary

Try to figure out generally what's happening and ask to check your understanding.

Read the docs and ask about codebase specific things.

If you're embarrassed or scared of commenting on the PR then send the developer a message. Most people are happy to help.