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.
Top comments (1)
This is especially true as a freelancer or as an employee conforming to corporate code policies (like we MUST use Webpack, we should use SASS, eslint-config-airbnb etc.) and requirements that one would never chose or advise otherwise.
I try to code modern, minimalist, fast, and accessible frontend design using mostly clean and minimalist code for my own projects like my portfolio website or side projects. Anything else will never ever become "my code" no matter what, as there are always too many "bad" decisions, or rather other people's decisions that I wouldn't agree to, so it's clearly not "my code" working in a project team, even if I have written the lines and git blame says so.
I like the notion of regarding the code as "my clients' code" and still try to improve quality, but don't get attached to the code personally.