Discussing the Issue of "Should You Fix Other People's Bugs?"

The Issue

Hello readers of 2coffee.dev, today let's take some time to have a conversation. The topic of today's article is "Should You Fix Other People's Bugs?" Well, this question might seem simple. Of course, when you work for the same company, on the same team, and the same product, everyone collaborates and fixes bugs together, right? Why even ask this question?

That might be the thought of many when it comes to fixing other people's bugs. But I believe that, aside from that, there are still people, including myself, a few years ago, who found this somewhat "hard to accept."

During my working years, all the companies I worked for were involved in some product, often referred to as "Products" companies. Being responsible for a position in a project, for example, a Backend or Frontend developer, means ensuring the development of features in their respective areas.

Typically, when making a decision to develop a new feature, after going through numerous steps to reach the "dev" team, the next step is to plan and assign tasks to each team member. For example, if a feature involves four main tasks after analysis, I might take on two parts, while others handle the remaining two. During the development process, I have to take full responsibility from start to finish until the feature is completed and released to users. This means that if there are bugs, QC will assign them to me, and I need to fix them.

However, when moving to a different team, the development process changes, especially when bugs are not assigned to the person who developed the feature but are randomly assigned to equivalent team members or at the discretion of the manager.

At this point, many issues start to arise. Trying to fix other people's bugs feels like having to fully understand their code before touching it. It took me more time to understand what others were thinking, more time to communicate, and even more time when the bugs I introduced outnumbered those I fixed. It was indeed a terrible experience, and I felt unreasonable for a long time.

The issues mentioned above only occur when intervening in deep logic, not to mention simple errors like syntax errors or missing filter conditions. If it's a simple error, anyone can recognize it and quickly fix it. But what I want to emphasize are more complex errors related to business logic. Yes, just hearing about it is already giving me a headache.

So, the question I asked at that time was: Why should I fix other people's bugs? Isn't it their responsibility, as they understand the code they wrote and should be responsible for correcting their mistakes?

Why Should You Fix Your Own Bugs?

Setting aside the emotionally charged question above, let's analyze the benefits of fixing your own bugs.

Firstly, I am the one who created the bug, so I need to take responsibility for it. Having to be accountable for the mistakes I made will make me more thoughtful when writing code because I know it's a mistake I caused and have to "punish" myself by fixing it. Imagine if a programmer, for whatever reason, keeps creating errors, and you are the one who has to bear the consequences. Would you be happy to accept that?

Moreover, they are the ones who created the logic and understand it. If there's a bug, they can quickly deduce where the error is or how to find it most efficiently, rather than guessing and spending more time on debugging.

Another part of it is due to the company's or team's culture. Depending on the way things have been done historically, each manager has a different management style, believing that whoever created the error should be the one to fix it to save time. In this workflow, QC also automatically assigns bugs to the person responsible for the feature. Doing so streamlines the process and saves a significant amount of time.

Why Should You Fix Other People's Bugs?

So, is fixing other people's bugs really as "terrible" as I once thought?

Firstly, one thing needs to be established: the source code belongs to the company or organization. Therefore, everyone is responsible, or in other words, everyone may have to take responsibility for the code in the project. Everyone needs to be prepared to fix any arising bugs. This places emphasis on personal responsibility and teamwork.

While it takes time to understand the logic before fixing bugs, in return, you can grasp someone else's work. If, by chance, the author of that code gets sick or, worse, leaves the job, other team members can step in and continue the work without interruption. When new team members join, the process repeats, and they quickly grasp the work culture, making it easier for them to adapt.

Improving the workflow is another aspect. Remember the advantages of fixing your own bugs; it can highlight an uncomfortable truth about an unstable workflow. Ask yourself: Why can't person A, who is on the same level as person B, fix B's errors? Suppose A says that B's code is hard to read and understand. Where does the problem lie when it comes to code review? Why allow B to write code that is hard to understand and still approve it? Perhaps there is no common rule for coding in the team? Similarly, maybe people didn't discuss the logic before starting the work? Only when the person primarily responsible for that logic is absent does no one understand what they wrote anymore.

So, Should You Fix Other People's Bugs?

From my perspective, you should, but it's not mandatory.

As mentioned, it depends a lot on the team's culture and the company's history. If your team allows individuals to fix their own bugs and finds everything smoother and faster, there's no reason to change. On the contrary, a team with a culture of "sharing" bugs among peers will transition to a more continuous workflow.

Conclusion

As I shared my story, I had never thought about fixing other people's bugs before. At the beginning, it felt irrational and uncomfortable to spend a lot of time re-reading someone else's logic, not understanding some parts, or being afraid to fix them because of the fear of introducing more errors. However, over time, the difficulties will pass, and you will gain a better understanding of the project. How about you? What do you think about this issue? Leave a comment below!