"There once was the first software engineering best-selling book. It was called The Psychology of Computer Programming (Weinberg 1971). There was a peculiar idea contained among the many excellent ideas of that book. It was the idea that the task of programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building.
...
What’s the alternative to an ego-invested programmer? A team-player programmer.
The team player sees the software product as a team effort and a team achievement. Error reports and reviews and questions become team inputs to help improve the product, not threatening attacks to derail progress.
...
But after further thought, this notion begins to unravel. It is all well and good to advocate egoless programming, but the fact of the matter is that human ego is a very natural thing, and it is difficult to find people who can—or even should—divorce their ego from their work.
...
A system that works will have to acknowledge fundamental human traits and work within the bounds they create. And ego is one of those traits.
"
- 'Facts and Fallacies of Software Engineering', Robert Glass, 2002
For practical purposes, if you don't acknowledge how good and bad behaviors can both spring from the same base emotions/thought processes then it's harder to grow out of the bad behaviors. You need to be able to reframe how the ego interacts with your work, not just try to kill it off.