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".
About Vinicius Brasil
Building cool stuff with Elixir, OTP and Ruby. Majoring in Theology and musician.
