I'll start this one with a bold statement: Most of the code running today is disposable.
Do I still have your attention? Good, then let me tell you what I mean by "disposable".
Code is of an ephemeral nature. Code that works perfectly today may be found buggy tomorrow and thus needs to be fixed. The platform code runs on may be updated and no longer compatible with the way things are done. The users require additional features, or the developer discovers that their understanding of the problem domain was inaccurate or incomplete. More and more changes are required over time.
Each time the code changes it ends up as something different. While this may sound obvious, its consequences are often ignored.
Time and time again, I see programmers becoming too attached to their code. I've done it myself a lot of times. It gets evidenced in several different ways, but I'll mention a few. I'm sure they'll help you identify many more that you have experienced yourself.
First scenario: A bug is reported about the software you're working on. When investigating the issue, you trace it back to a piece of code that you yourself wrote a few days/weeks/months ago (or, even worse, someone else discovers that the issue was introduced by code you wrote and brings it up). After looking at the code, it turns out it's a pretty obvious logical mistake, or an edge case that you have already considered in dozens of ofther parts of the code, but not there. The most common first reaction to that situation would be to try to justify why you did it that way.
Second scenario: While performing a code review, you discover that the changes include several lines of commented out code. You ask the developer that made the change about it, suggesting to delete them instead. The developer responds that they are commented out because the functionality might be needed in the future.
Third scenario: While making changes to the code, you decide to take a shortcut due to time constraints, with the idea of "fixing it later". Due to the project priorities and constraints, the fix keeps getting pushed down, so it never happens.
In all these scenarios are examples of code that needs to be replaced. These have all happened to me in one form or another, and I'm sure they have happened to you as well (if not, just wait a bit).
Code is a living thing, and is a common aphorism that software is never truly done. As long as a program is being used, new features will be requested by their users, or bugs will be reported. The only pieces of software that no longer change are either not being used or not being maintained.
For these reasons, any code you write today will almost certainly need to be updated tomorrow. But we, as human beings, are usually too attached to our creations, and have a sense of posession that is not really compatible with this reality. Software projects are built by teams, not individuals. Once you have finished writing a piece of code and pushed it to the team's source control repository it's no longer "yours". It belongs to the team, and anyone in the team should feel free to change it, expand it or delete it entirely based on the project's needs.
Also, because of this, it's not relevant who wrote the code that is causing a malfunction or a regression bug. It's the team's code and everyone should take care of it. Finger-pointing is not productive, and so, there's no gain in putting the blame on any one person. Many developers are overly defensive about criticisms to their code changes, and that is usually the fault of the critics. Code criticism and comments should be as blameless and dispassionate as possible. That is the only way to demonstrate empathy for the person who wrote it.
I'd like to ask you to think about code as disposable, and try to always consider whether it's best for the project as a whole to keep around a bit longer that piece of code you're working on, of if it's already time to replace it with something different.