Embracing Code Review as an Opportunity, not Opposition


3 min read

When I first started my career, one of the scariest procedures for me was submitting my pull requests for Code Review.

What are code reviews?

Code reviews typically happen once your code is feature-complete and tested. You will make a new branch with your changes, then make a pull request against your application repo. After the PR is made, you submit it to others on your team for review.

My team in particular had a 3 review system at this time, focused on: Code quality, Security, and a final manager green light.

I don't think this is always such a scary process for everyone, but it was for me.

This was to no fault of the other devs on my team, they're lovely folks and super skilled to bat. We have a great culture.

Everyone is friendly, and they are willing to help any time you ask. I appreciate it more than they'll know!

Yet, on the day my pull request's functionality was complete, tests were passing, and the risk level was determined, I still found it difficult to submit it for review.

This ended up dragging into the next day while I shrunk in fear. I reached out to my manager. It was my first-ever PR as a developer at this big new company, and while I felt like it was ready,

I was worried.

I was worried that my reviewer could've found my PR after a long day,

I was worried that they'd provide feedback to my manager that my code sucked,

I was worried that the company would realize I was a fraud and chase me out with torches and pitchforks,

I was worried that everything could collapse.

But my manager recognized my concerns, and instead of making me feel silly for being anxious, encouraged me to push through that feeling.

To use Code Review as an Opportunity, not Opposition.

And I did.

After I requested a review, I closed my laptop and waited. Eventually, I got a notification on my phone from Outlook.

It was my review.

Uh oh.

For a moment, my worst fears came true. I saw that a Senior Developer had requested changes and I was petrified.

He's been at the company for years now, what will he think?

I continued to persist. I read through his comments.

He provided TONS of valuable feedback.

Things I hadn't considered. Test cases I had entirely missed. Variables and functions I wasn't using anymore. More declarative names.

He had spent about 15 minutes reviewing the code, then found more glaring holes than I could've ever imagined at the time.

The PR I thought was complete, which I had been staring at for a week, was flawed.

So I adopted his changes. And the code was better, cleaner, and easier to understand for it. I learned. He taught.

It was an opportunity to grow. Not opposition.

He didn't want to make anyone feel bad. He wasn't prideful. He wasn't interested in playing ego games. He didn't pull his seniority card.

He just wanted better code in the system. So he showed me how to do that.

He probably does not know how nervous I was, and he never needs to, so don't tell him! Nonetheless, I recognize it as a transformative moment for me, and finally, a chance to break out of my feedback-aversive shell.

It's hard to be a developer. I understand all too well that feeling of insecurity and the drain of comparison.

This story occurred a couple of years ago now, and while I still get nervous submitting code reviews from time to time, it helps me to remember that there's a lot more going on than what we're worried about.

Don't shrink.

Remember that this is an Opportunity, not Opposition.

Feedback will not destroy you. Only better you.

Thanks for reading!