It doesn’t matter care how long you’ve been programming for. It doesn’t matter how meticulously checked your own code for errors. It doesn’t matter how many tests you wrote. You could have the best linters in the world. You could reread the style guide and best practices documents of your team a million times.

On the first non-trivial code review, you’re going to get a lot of comments.

A lot may end up being around 10 if you really check your work and generally follow good coding practices. If you are generally a sloppy programmer, don’t comment, don’t test and don’t check your work, you might hit triple digits.

This is a right of passage. Every programmer has their first code review, and it’s terrifying. It’s like someone’s live streaming a reading of your diary on a projector screen.

Up until then, you normally hide away under a blanket in your musky corner of the team space and probably write horrifying incantations that should never see the light of day. In previous teams, you may not have done code reviews at all so that terrible code hit master with all that code gunk still attached to it.

Well, now it’s time to ascend to the next level of programming. Code reviews are quite possibly the best way to improve as a programmer. There’s a few reasons why.

Other People Mastered Other Things

No matter if you are a freshman in Mead’s class or an industry professional, you and your peers deviated at some point. They picked up different topics better than you. They watched some tutorial on YouTube that you didn’t. Maybe they had experience in another language.

That experience will often lead them to suggest things you never would have thought of. Each of my teammates generally caught different types of mistakes or inefficiencies in my code. One was particularly good at multithreading. If something was a potential deadlock, slow, embarrassingly parallel, or error prone, he’d catch it. Another teammate was great at finding efficient algorithms. Another was great at catching resource errors due to missing lines (generally in the event system). Another was great at obscure keywords that I was terrible at using (const, explicit, final, etc).

Code reviews often became a way to learn new things about C++ and programming. I know what I know about parallelism from code reviews and eventually using it a few times in our engine. Yeah, I took a course on it too and it definitely helped, but I had learned this beforehand.

You’ve Been Reading Your Code Too Long

After multiple days of slaving away at code, you start to skip over whole sections of it. The constructor/destructor disappears. The file comments blur. The function comments may as well be in Klingon.

I don’t think there’s a programmer on Earth who hasn’t worked well past midnight to finish their code. You feel kind of awake and think you just need that last ten minutes or so to finish. Two hours later, it’s 4 am, you’re stuck on how to iterate over a vector and fall asleep in your chair.

You need someone else to read it.

That second person is looking at your code differently. They might not know what the purpose of it is. They might not know what algorithm you used. They’re actually going to read the comments!

Guess what. That’s what someone is going to do if they need to debug your code down the road. They’re going to go into your files with no idea what they do and survive on your code clarity and comments. You’re preparing this file for the future debuggers of your game.

That algorithm that you thought was perfect might be completely overthought. That code you thought made sense might look like black magic to someone else. That comment you thought explained the code may have made everything more complicated.

This is where you kind of don’t get to choose if something is simple enough. You’re sort of “playtesting” your own code so to speak. If someone else reads it and goes:

“What.”

You don’t get to say that they just don’t get it. If someone calls your game confusing or clunky, you as the developer (I hope) would never go “You just don’t understand”. Yes. This is the point. They don’t understand.

Take their comments to heart. Try to make it as clear as possible. Remember, the most valuable resource on your team is your own time. If you are wasting the time of anyone reading your code because it makes it 0.1% faster, you’re writing bad code.

You Do, In Fact, Make Mistakes

Shocking.

Here’s some common ones:

• You change one last thing before pushing and forget to test it.
• You forgot to push a file/resource.
• You didn’t catch an edge case.
• One of your tests doesn’t actually test anything (always passes).
• One of your features has an overflow error and happened to work when you tested it.
• You spelled something wrong in a comment.
• You got cut off mid sentence in a comment and forgot to resume it.
• You didn’t follow the style guide on something that isn’t caught by a linter.
• You accidentally pushed some experimental code.
• You left some debug lines in.
• You forgot to remove a comment with a swear in it.
• You forgot to put the DigiPen copyright header in.
• You didn’t comment one of the functions in the header.
• One of the templates never gets called and so you never see that it doesn’t compile.
• You misspelled a string tag so it doesn’t match up with something expecting the correct spelling.
• You didn’t clean up your memory in the destructor.
• In multithreaded code, you didn’t give your lock_guard a name.
• You accidentally hit the keyboard and pushed with a random Q in the code somewhere.

Get my point? There’s a lot of ways to mess up. One character can ruin an entire program. Having another set of eyes helps catch that.

Enough of the why. Let’s talk about how.