Coding without Ego

I think an often overlooked quality that makes a software developer “senior” is that they don’t feel like they need to defend their code, that they are open to changing directions and to doing it another way.

However, I also think there are “senior” developers out there that simply want to do it their way and don’t care what others think. That is ok too; just not great if you want to help others grow.


What is the ego? You ask google and it will tell you “a person’s sense of self-esteem or self-importance.”. It makes me think that if I am not defending my self-importance that I might just let others run the show. This “defense” can be distilled down to one’s own pride. We are often told to take “pride” in our work, but no one really said to take some pride, but be open to feedback because it probably could be improved.


I remember taking so much pride in my code that if someone said anything about it, I would take it personally. I think anyone who is a programmer knows what I am talking about. Well, there’s no getting around it and it is just part of the journey! Often times I think a new developer is so eager that she or he works relentlessly to learn all of the things…I mean the learning tracks nowadays are nuts! It’s no wonder so many of us get so burned out and then have to deal with imposter syndrome. 😩😩😩


Given today’s climate, it is very difficult to feel comfortable. This was why I wrote about staying uncomfortable; you simply cannot keep up and might as well just accept it.

Working at Zeal we pair program a lot. Sure, there’s a lot of debate about this; some do not like pairing others do. If it isn’t your thing, no big deal, but I think we can all take something away from pairing that has nothing to do with writing code and getting a product shipped.

I remember my first pairing experience. It was kinda like all of sudden I was on a stage and was live coding, which back then was scary for me. Thankfully the folks at Zeal were kind to me and showed me the way with kindness and thoughtfulness. It was an experience that set the tone for me and how I approach pairing.

Simply put, I code (and pair) without ego. I do not identify with my code. The things that I do try to identify with are:

  • Readability
  • Maintainability
  • Testability

These 3 things are more often than not the most important things for me as I am writing code. All of these are selfless and require that I do things that might be uncomfortable. A refactor that I just don’t feel like doing or oftentimes listening to my pair and realizing that I am wrong.

Nobody loves brown field code, but it can better if we write code that is easier to read, update and test. That is indisputable.


I do believe that empathy is gaining more and more momentum as a fundamental skill for a software developer. But, how do you teach this? Well, for starters let’s ask google again what this is: “the ability to understand and share the feelings of another.” Pretty straight forward definition, but in practice, we have all these hurdles in our mind. The biggest is our own ego. Ego is nearly the antithesis of empathy.

It certainly is good to feel good about the work you do and you should! However, this doesn’t help others feel good. This is where empathy comes in and is equally important to be aware of as ego. When pairing empathy is paramount, especially if you are in a position of seniority, it can be quite threatening to your pair. In these scenarios your collective result will be colored by the subtle tension between you and your pair; the code will simply not be as good as it could have been.

When pairing, ask yourself (be honest):

  • Am I resisting input from my pair? If so, ask why? Probably not a good reason…
  • Is there a sense of flow? If not, where is the resistance?
  • Where are my reactions coming from? Am I reacting out of compassion or fear?

There are many questions you can ask yourself, but the point is to become aware. Pairing can be a humbling experience for many. It can be a bit painful on bad days, but on good days it can be a greater experience than coding solo. It can be even better when ego and empathy are balanced. The key is awareness.

Be aware of how your pair is feeling.

Be Better than Yesterday

It is our ego that makes us feel like an imposter or that we didn’t do a “good enough” job. It is a hollow feeling and sucks for sure. However, this is a lie; we did do a “good enough” job and we are not an imposter. At least that is what our best friend would tell us. But, this isn’t what we tell ourselves, we are our own worst enemy unless we become aware of it. So, pay attention to what is going on in your mind, specifically that inner dialog. Simply through awareness, you can improve your own world and make today a little better.

Paying attention to your thoughts helps, but only goes so far. Not feeling bad is better than feeling bad. But, feeling good is certainly better than not feeling bad. It is a funny thing that when we help others we get a sense of fulfillment. It is like free happy points. Honestly, give it a try. Go out of your way, do something unexpected for a stranger that simply makes their day. You will have a rush of feel-good neurotransmitters and your overall sense of well being will be much higher!

It is the Balance

To bring it together, I believe we can all write better code by balancing our ego with empathy. Be proud of whatever you do, because you should feel good about yourself. But, at the same time, you should feel that same sense of pride in others as you acknowledge their triumphs.

The balance is tricky, but essentially be selfish, but also be selfless.