I'm Starting to Understand That Code Reviews Aren't Exams

In April of last year, I changed careers and became an IT engineer.
Since then, I’ve been working remotely on maintenance and development.

For about ten months after joining, I was implementing tasks assigned by the tech lead, submitting pull requests (PRs), and having them reviewed.
That cycle repeated over and over.

Working on implementations and solving technical problems has been enjoyable.
But at the same time, I felt a certain pressure when getting my code reviewed.
I think that’s because, unconsciously, I believed I needed to figure out the “correct answer” that the reviewer had in mind.

This way of thinking likely stemmed from two things:
a sense of inferiority from being a mid-career newcomer with little knowledge or experience,
and the mindset I had brought with me from my previous job.

What I realized after starting to do reviews myself

As I began reviewing others’ code myself, my perception of code reviews changed significantly.
I came to realize that a review isn’t an exam, but rather a place where we bring our knowledge and judgment together to create something better.

When I write review comments, I sometimes propose solutions based on past problems I’ve faced or what I already know.
But I don’t believe that my suggestion is the one correct answer.
It’s just a proposal—and if there’s a better one, I want to go with that.
That’s the mindset I try to bring into my reviews.

Because of that shift in perspective, I’ve started to see comments on my own PRs not as criticism, but as welcome feedback.
And the anxiety and discouragement I used to feel around reviews has gradually faded.

Infallibility doesn’t exist

Even code that’s been merged after review often gets revised later, or redone entirely because of spec changes.
Even if I spend time building out an unfinished feature, I often end up refactoring or fixing bugs later.

Through these experiences, I’ve come to accept—on a real, personal level—that what seems best at the time can change later, and that there is no absolute correct answer.

On the flip side, I’ve become more aware that my own ideas and designs can directly affect the overall quality of the product.
Rather than just building what I’m told, I now feel I have more control and influence over the product through my own judgment and proposals.
I feel like I’ve started to participate more actively in development.

Why I hadn’t realized this until now

These are all things that seem obvious as knowledge—but why hadn’t I truly felt them until now?

I think it’s because I hadn’t yet stepped out of the mindset of being “someone who’s being evaluated.”
And also because of the culture I had internalized in my previous job.

I used to work as a government official, and from what I remember, infallibility was strongly emphasized in that environment.
There was a heavy focus on precedent, formality, and a formal decision-making process designed to avoid mistakes at all costs.

I think I brought that mindset with me when I became an engineer—
and unconsciously equated “approval” with “review.”

From here on

Going forward, I want to pay even more attention to how I write comments during reviews.
Having gone through what I described above, I understand that how a comment is received can vary greatly depending on the recipient’s context.

That’s why I want to make sure it naturally comes across that “this is just one suggestion, and I don’t think my opinion is the only correct one.”
I want to express a mindset of looking for better options together in the way I write my comments.