I refer to the code I write as "MY CODE."

In reality, it's my client's code the majority of the time.

The Problem

In the past, this caused issues when I would push up a Pull-Request and ask for a Code Review.

The reviews would come in.

I read them.

I got angry.

How dare anyone question "MY CODE?"

I got defensive and struggled to see the need for someone to look over the great code I was writing.

The Issue

The issue was that it wasn't my code.

The issue was that it wasn't always great code.

The Situation

The code I wrote was for the client. The Code Reviews were made to improve the code I wrote.

The only difference here was my perspective.

The reviews hadn't changed.

The reviews were never an attack on my code, any by extension me.

They were only meant to help me: improve my code, see other perspectives, and grow as a developer.

The Code Review

Considering the subject of code review itself (the code), there are two conceptual levels at play.

A code review has important human ramifications. People learn and share knowledge through the review process. And they use it to prevent the kind of defects that result in frustration for the team. Developers get emotionally invested in their creations (we own the code we write).

A good code review process helps with code quality and helps developers learn. It is the most effective defect prevention method. This put a good code review ahead of even automated unit tests.

Conclusion

I find that maintaining this balance of code ownership to be a challenge that comes back to visit me now and then.

When I first started and had my first code reviews it was much more challenging. I often find myself working with other developers to ensure that they understand my intent to help them learn and grow throughout this process.