Don't be protective of your code

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".