You spent hours and hours writing code. You are ready to submit your changes for code review. *Notification bell rings*. Changes were requested, code suggestions, potential bugs, and clean code issues. You get pissed.
Let's imagine another situation. Your feature gets merged to production. Weeks later you get a message from operations saying something is not working. You get defensive and assume they must be using it wrong.
That is the result of being protective of your code. Even though I love coding, I'm confident the value I deliver is not code. The end of my work is not the code itself, but the product I'm building. However, it doesn't mean my code doesn't need to be clean and easy to read, as those are to make the product extensible in the future. Software engineers that are protective of their code, don't understand that programming is a tool. It's for sure crucial, but not the final work. True problem-solvers use their technical skills as a tool.
Seasoned engineers know code is merely the paintbrush for good art. Being protective of your code slows you down in the following ways:
- You get offended when taking feedback
- Makes you blind to potential bugs
- Prevents you from learning from other developers
- Causes you to think code reviews are personal
- Closes yourself to criticism and advice
This is the second installment of short reads about common career problems engineers face. If that sounds interesting, I invite you to read "The fear of merging".
For me, code has always been closer to art than engineering. Writing it is a personal thing, and it's natural to become somewhat attached to it.
Yes, it delivers functional value - but there is also a poetry of logic in there... your intricate thought processes rendered in code.
Viewing it as purely utilitarian would be a horrible way to approach it... I don't understand how or why you'd want to work like that.
I think this is why some developers become annoyed in code reviews. I don't think it is really protectiveness - just a frustration coming from a totally different way of seeing code, that others don't share.
I know I'm not alone in this mindset, but maybe it's not so common?
I've been writing code for 39 years.