5,601 reads

You Are Not The Code You Write

by Fagner BrackFebruary 22nd, 2017

Too Long; Didn't Read

There are some places where the police advise you to not treat your vehicle as a person. Let’s say you’re in a dangerous situation and you need to jump from the vehicle while on high speed. If you treat it as your "baby", then your instinct is gonna be to stay and save it. However, if you let it go, the chances of surviving can be bigger.

Companies Mentioned

featured image - You Are Not The Code You Write

Criticism to your code is not criticism to you

Listen to the audio version!

A vehicle is just a machine.

As Humans, we tend to attach feelings to objects because we care. However, they don’t care about us.

The same attachment can happen to the code.

We say a developer is married with the code when they don't feel comfortable when somebody wants to change something they wrote.

The reason why they do that can vary. However, there are some common patterns:

Some developers tend to create a huge sense of attachment to what they do as if their work represents their "baby" and any criticism to it is taken personally.
Some developers can consider the code as a fundamental representation of themselves, like a unique work of art, and any criticism of their work is interpreted as criticism to themselves.

There are people who can overcome those effects by having a different mindset. They understand that you are not the code you write.

Criticism to your code is not a criticism to you. Just because you wrote a crap code in the past, for whatever reason, that doesn’t mean you’re a crap developer. The code is crap, not you. You never were.

There’s an interesting principle people use when doing retrospectives called “The Retrospective Prime Directive”, which says:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

With code is the same.

There’s always something to improve and we should believe everyone did their best at the time given the circumstances.

The code is just like a car or motorcycle. It’s a lifeless tool and you shouldn’t be attaching feelings to it.

If you treat the code as your "baby" or as a representation of yourself, then:

When somebody presents a better solution you’ll be defensive and refuse to change. It will hurt your own self-improvement and prevent you from working as a team.
When the scope of a project change, you'll become frustrated for having to change everything you've done so far. It will create unnecessary stress and conflict.
When working with your own side-project, you will not make it Open-Source for being scared of criticism. That will hide what you've done from the world and block you from receiving quality feedback.

The author of the most loved and most hated library in the history of JavaScript said in a blog post a long time ago:

I have learned that in the open-source world, you are not your code. A critique of your project is not tantamount to a personal attack. An alternative take on the problem your software solves is not hostile or divisive. It is simply the result of a regenerative process, driven by an unending desire to improve the status quo.

The project scope changes, time passes by, people improve, individuals come and go and the code stays the same. Stop caring about the ship that already sailed and start caring about the new ships you’re gonna build.

Be comfortable that people will look one year from now at the code you will write today and criticize it. Those "people" can be even yourself, for that the goal is not to insult, but to learn with the past in order to understand the present and create a better future.