If you want to be successful at writing code, then you’d best keep your ego out of it. That’s the essence of egoless programming, a concept first written about by the legendary author Gerald M. Weinberg. To industry outsiders it might seem bizarre that we need a term to describe this concept at all, since it’s not only programmers who suffer inflated egos. But anyone who’s worked with programmers for any period of time knows that egos are everywhere—it’s almost as if we breed them. If they haven’t got in the way of your work yet, then they undoubtedly will soon. Just give it enough time.
Why is it that this is such a common problem in software? Could it be that programmers are somehow more likely to be afflicted than the general population? Does the nature of our work bring out the worst in us?
To answer these questions, let’s take a look at a couple of examples from our daily work.
The true value of pairing
Have you ever had a colleague who refused to pair?
“I’ll work slower!” they argue.
“We’ll only get half as much done!”
If you could hear their ego speak, it might say, “I can write code just fine on my own, thank you very much!”
Sometimes, we don’t want to pair because we’re afraid of making mistakes and being critiqued. This is the ego at work: it protects our pride.
Those programmers who have learned to disguise their pride might say, “Sure! I’d love to try pairing one day, but not right now as this current story is very important and if I have to pair I might not finish it on time!”
Of course, some of us believe that it’s the most critical code that always needs at least two pairs of eyes.
Tasked with building a new feature, the egoistic programmer wants nothing more than to bury their face in the screen, to beaver away furiously for hours and then finally—at the end of a Herculean effort—to sit up, point at the screen and shout out, “Look at me! Look at this beautiful, shiny thing that I’ve created!” The rest of the team grumble and feign delight. The programmer’s ego is validated once more. Meanwhile, the team becomes a little more fractured.
Solo work is a smoke-and-mirrors practice. It allows one to pretend that mistakes didn’t happen along the way, that typos weren’t made and dead-ends not followed, and that the final product is the only thing that ever existed. The ego relies on this illusion of perfection. Pairing destroys it because mistakes are spotted immediately and the culprit is obvious. Without the illusion, there can be no validation. The ego cannot be fed.
Fighting back
Learning how to pair can be a harrowing experience. When we first sit down with another programmer, the brain panics as it quickly assesses each and every insecurity: do I type fast enough? Accurately enough? Do I know how to use my IDE effectively? Do I know all those keywords? Am I going to name things well? Find the simplest algorithm?
The adrenaline flows through our veins as we realise just how vulnerable we are. Our pride is being assaulted on all fronts. We might manage just 30 minutes before we feel exhausted; after all, fighting these strong emotional responses takes a lot of energy.
How often have you heard someone say that pairing is tiring? That they can’t do a full day?
When you make yourself vulnerable to the scrutiny of your pair, you reinforce the positive emotions associated with pairing. Over time, you come to understand that your own code is improving from the instant guidance of others. You learn that your colleagues do not care all that much when you make schoolchild errors. They’d rather just help you fix them and then move on to the next thing. Together, you are writing code that harbors fewer bugs. Throughout this process, you are taming your ego.
With enough practice at locking your ego in a box, you’ll eventually become comfortable with pairing all day, every day.
When others just don’t meet your standards
Imagine how you would feel in the following scenario. You arrive at work one morning to find that all the code you wrote last week is gone. Your team lead rewrote it overnight because they felt they could do a better job, even though the code worked just fine and had no bugs. If this happened to you, you’d be pretty upset, right? No doubt it would be pretty demoralizing.
Now think of it from the reverse point of view. A chunk of new code, written by your colleague, causes you so much anguish that you rewrite it immediately, without their input.
This issue is not about who is right and who is wrong. It’s about the emotional dependence on the codebase. There are negative feelings on both sides, and those feelings are rooted in the code. But there’s no reason why this should be the case. No codebase is perfect. We make mistakes; we’re only human. If you tie your emotional well-being to the state of the codebase then you are in for a rocky ride—guaranteed. Why not just accept that the code will either be good or bad, and that both of those states are okay? Bad code does not have to equate to bad feelings.
If you think this doesn’t apply to you, think about how you’d feel if I deleted the last source file you’d written, and wiped it from source control. Would you be angry? Would you feel a sense of loss? How long would you let these emotions affect you before moving on? A minute? A day? A week? Or maybe more?
The egoless programmer is not devoid of emotion, but they have learnt to not let code affect their mental state.
It’s only code
Yes, we may have deadlines; we may have commitments; we may even have a desire to have the cleanest code at all times. But if you find yourself feeling negatively because of code that you’re working with, take time to stop and think that through. What happened to get you to this point? What is it within you that makes you feel that way? Sometimes all that’s needed is a shift in perspective.
Rather than rewriting the code, the team lead could opt to wait. Waiting in itself can seem like a hard thing to do. It’s very easy to become impatient and feel an immense pressure to rush, particularly when we’re approaching the end of a sprint. The ego is protecting us from the shame of falling behind schedule.
But waiting is not even the hardest part! The discussion itself could easily cause hurt feelings on either side. If you’re in a similar situation to this team lead, put your ego aside before going into that conversation. Do not start from a position of anger, but instead try to be empathetic, remembering that your colleague will probably have a better day if you treat them with humility and respect.
You could also open it up to the team for discussion. Having an established forum such as weekly lunch coding sessions can be a great way to handle exactly these scenarios, because people tend to be more considerate when speaking in a group setting.
There’s also another option. The team lead could realise that even though the code isn’t written exactly how they’d write it, it is working and can be left alone. That’s a trade-off that recognises that human relationships can often be more important than code quality.
Taking a step forward
Our work is inherently creative. Each time we take up the keyboard we are building and creating something from nothing, just like an artist or musician might do. But unlike art or music, we have been taught that some code is objectively good and some code is objectively bad. Clean code is good. Buggy code is bad. Test-driven code is good. Comments are bad. The list goes on.
It doesn’t take much time as a programmer before we realize how much relentless criticism we must endure. But since this is our creative work, we instinctively want to take joy and pleasure from it. How can that happen when we’re constantly being attacked for our work? It’s no wonder that we become defensive. The egos we build protect against the emotional attacks we face.
However, there’s another approach: remove your self from your code.
Before moving on from this article, I’d encourage you to take a couple of minutes to think back over the past month and recall a time that you haven’t felt at ease in your daily job. Think about what made you feel that way. Ask yourself if the situation really justified the amount of suffering that you inflicted on yourself. Now think about a time when you reacted negatively toward the work of a colleague. How do you think you made them feel? Could you have approached the problem in a different, kinder way?
Weinberg wrote about egoless programming in his book The Psychology of Computer Programming, first published in 1971. That’s almost half a century ago. It is one of the few computing books of its time that remains relevant. The craftsmanship movement owes much to the ideas within it, not least of all egoless programming.
The human cost of coding is still not well understood. But if you’re looking for improved work satisfaction, then Weinberg has some good advice for you: you are not your code.
