As software developers, we often become overly attached to the code we write. Over the past few years, as I’ve grown into a more senior position, I have realized that this is an anti-pattern that can cause serious problems if left unchecked.
Embracing the idea of “egolessness” in software development has made me a much happier and productive developer. I don’t mean “ego” in the traditional sense i.e an inflated sense of self-worth, but rather the attachment of one’s self image to an external entity like code.
Personal attachment to code
Software development is an inherently creative endeavor. It is natural for creators to become attached to their creations. However, this can get to the point where a developer sees her code as a reflection of her self. This only leads down a path of unhappiness - the developer becomes overly defensive to constructive criticism of their code and becomes resistant to change.
Detaching your ego from your code makes you more receptive to feedback during code reviews and helps you become a better developer overall. As Gerald Weinberg put it in his book The Psychology of Computer Programming, “You are not your code”. The best senior developer I have worked with took suggestions from even the most junior developers seriously.
Flawed mental model
Most developers have mental models of how a particular software system works. This model might hold up most times, but may fall apart at the edges. Being open to continually revisiting and updating this mental model as we obtain more data about the system is extremely important.
Several times while debugging difficult production issues, I have observed that a flawed mental model has closed off my thinking to an avenue that leads to the root cause.
Checking your ego at the door and conceding that you don’t fully understand the system and all its interactions will decrease frustration and time to identify the root cause.
Protecting others’ ego
Many software engineering organizations have people with big egos. Their teammates are loathe to critique their code or send pull requests to code they own. This situation can become amplified when said code has critical bugs that need to be fixed.
This may be a little controversial, but I believe that the teammates in this situtation should stand up for what they believe is the right thing to do and make their arguments as non-confrontationally as possible. Critiquing design and code, and not the person should be the focus.
In summary, consciously recognizing when my ego is in the way and actively being open to being wrong has helped me be a much improved and happier developer.