The Code Ownership Feeling

Every developer, sometime in their lives, or very often pass through this feeling. You write code and it feels like it’s a part of you, thus motivating you to write the best code in the world, or at least what you consider it to be

That’s a good thing if we take into account that you increasingly want to take care of the project, establish patterns and think about more ways of improving your code and scaling the system. However, this feeling of ownership can usually have some negative aspects as well.

Imagine that you work in a team and not only you, but more people will be modifying the project. Even if you set code writing patterns, structure patterns for testing and write a hundred pages of documentation with good practices, the other developers will not write exactly the same way as you do, or use the same approach you would. These are the moments when that code ownership feeling will start to bother you.

The fact that it bothers you, is not a problem, but it’s important to evaluate your attitudes toward different ways of thinking.

It’s important that you analyze what is good or not for the project, and not what is different from your opinion, or what hurts your ego.

I think it’s valid we ask ourselves some questions, to not become authoritarian, but collaborative people:

When someone brings up a solution different than yours, do you consider the possibility that this solution can be better, or do you disagree, thinking that your solution is already good enough?

If you are used to disagreeing right away, you are doing this wrong. You have to consider the possibility that you are are wrong or that the other idea can be better. There are many different ways to think about a problem and simpler solutions can come from the people you least expect. You have to make room for others to talk and listen to what others have to say if you want to be a better team player.

Do you usually ask people to do tasks without explaining the reasons?

If you delegate a task that has no explicit reason and you don’t explain why that task should be done, you are discouraging the person to think. Talking for myself, I just can’t do a task without knowing the scope and the reason for it. I need to understand what is the expected outcome, so I can figure out the best way of accomplishing the task, which will later be reviewed by others in my team. As a developer, I get paid to THINK and not only to write code!

When you give a opposite opinion, are you usually vague?

When someone suggests a solution and you disagree with it, you should be clear and objective on why you disagree. If you usually disagree without arguments, just using vague phrases like it: “I just don’t like this way, it’s not cool”, it may seem that you don’t agree just because it’s not your way of doing that.

Are you usually not open to different opinions and new ideas?

Always be open to new ideas, especially from new people in the team. Those people come with another vision, they don’t have the “Group addictions” as the others, who have been in the project for a longer time.

That doesn’t mean that you should always do everything they suggest, but the merge of ideas can create a solution that was never thought before.

Talking about Group addictions, the video below shows an experiment about Behavioral analysis. It’s essential to watch.

We should ask those questions frequently to not allow us to think that, a person with lower experience has nothing to teach.

And always remember: Code is not written in stone, code is something alive that changes frequently.

For anyone who would like to read more about this topic, I highly recommend this article from Tiago Garcia, explaining the concept of collective code ownership: Be a thoughtful programmer by exercising more collective ownership.