The egoless developer

The egoless developer and what it means

Before we dive into the origins of this term and who wrote it, I'd like to share my thoughts on what it means to be an egoless developer and why it is still very much relevant today as to when it was written back in 1971. Here's an example scenario that I've seen play out and one I've been a part of myself in the past.

Developer A gets ready to submit a code review, thinking, “My code is good, but maybe there are a few problems with it, but there shouldn't be too many changes I have to make.” And they hit submit on creating the code review.

The next day Developer A sees a whole slew of comments on their code. It seems like every single line someone has found issue with. Some of it wasn't even written by them! How dare the other developers attack them so! Out come the excuses and deflections:

• I have no idea why someone would write it that way. That's how I found it!
• Clearly this doesn't need a unit test; there's no way it could break. (Even though a reviewer has pointed out one or two likely scenarios.)
• I just saw a similar piece of code pass code review last week. Why didn't you catch this (includes link to offending code)?

And on and on it goes. Developer A immediately felt like they were personally being attacked and responded in kind.

Does this scenario sound at all familiar? If you haven't been on one side, you've probably been on the other side of this interaction where someone whose code you just reviewed seems to have taken a personal offense to you pointing out some issues with their code. The fact is that software developers are human (I know it's hard to believe, but it is true), and humans will lash out when they feel like they are being attacked. Did you mean to attack them? Of course not (well, I hope not at least), but people may get defensive for any number of reasons. They may feel that other members on the team know more than they do and feel inadequate, they're under the gun to get this in for testing, or maybe they're having a stressful day or week. Whatever the case may be, they are going to act defensive to any kind of critique of their code.

The ten commandments of being an egoless developer

How, then, do you remove yourself, your ego, from this situation? This is where the 10 commandments of an egoless developer come in to play in helping you to address these types of situations. These originally came up in the book "ThePsychology of Computer Programming" by Gerald M. Weinberg in 1971.

1. Understand and accept that you will make mistakes. Even seasoned developers make mistakes. I've rarely seen any code run out of the gate immediately. What you want to do though is to ensure that those mistakes are caught as early in the pipeline as possible. As developers, we should have tools and processes in place to help with this: static code review tools, peer code reviews, automated tests, and QA tests are just a few of these mechanisms that prevent mistakes from finding their way to a customer.
2. You are not your code. This one is especially hard for almost every developer I know. You wrote this code; it is, by essence, an extension of you. But try and think about it from this perspective - have you ever looked at code that you wrote 2 months later, 6 months later, or even a year later and wondered who wrote it? Or how in the world you could have written it? You change and grow as a developer, as will your code. One of the best ways to grow is to be able to objectively look at your own code and admit that you could have written it better or taken a different approach.
3. No matter how much "karate" you know, someone else will always know more. There will always be someone who knows more about a particular aspect of something. Maybe it's the domain you're working in, maybe it's a particular technique or language feature. If you stop and listen, you may learn something. If you ask them to show you, you will almost definitely learn something.
4. Don't rewrite code without consultation. Are the changes you would like to make more stylistic than functional? Are you fixing a real problem or are you merely making something match your perception of what it should be? If it feels more like the latter, then it's possible this should be a team decision and not a singular one. This isn't to say that stylistic changes aren't welcome or warranted, but rather that it should be a consensus and not a one-person show.
5. Treat people who know less than you with respect, deference, and patience. Sometimes, especially during a code review, someone may make a suggested change that won't work. Should you fly off the handle and tell them how stupid they are? No. Use this moment to try and explain to them why a particular approach or fix won't work. Who knows, you may come back with a new understanding of their approach and see that it may actually work if tweaked. The same goes for people outside of the engineering department. You will find yourself working with people from across the company and have to explain very technical things in ways that make sense to them. This is where you get to flex and grow your communication skills. Also, they probably have a much greater understanding of the business domain than you do, and you'll need them to explain that to you as well.
6. The only constant in the world is change. The one thing that has served me well over the years is this maxim - every change is an opportunity. It could be an opportunity to learn, it could be an opportunity to advance my career, it could be an opportunity to change my perspective. The point you should be taking away from this is that change is, indeed, inevitable and if you want to succeed as a developer, you should not only get used to it, but be prepared to embrace it.
7. The only true authority stems from knowledge, not from position. If you want to have authority, the best way to gain it is to show that you have the knowledge required. I don't mean this to say that you can rattle off statistics, etc., but that you can coherently explain not only what your application does it but why. The why behind things is much more important than the what. If you don't understand the why, you will never truly understand the core functionality. It is this type of knowledge that leads people to say, "Oh, you want to understand the auth system? Go talk to Dave, he knows that thing inside and out."
8. Fight for what you believe, but gracefully accept defeat. We all have specific things we are passionate about. It could be about architecture, it could be about a specific new framework that we really love, or it could be about how well a particular language would handle a problem. It's great to be passionate about those things; however, we can't use that as a barrier for others. I'll use an example. At one point, I was a huge proponent of XML. In fact, I wanted to write an IDE that used XML to store the source code (it was a little crazy I freely admit), but as I saw things in the industry start to shift and move away from using XML, what I didn't do was dig in my heels and continue to demand that we use it in places that didn't make any sense. My point here is that you may believe strongly in something, but if your arguments haven't won over the rest of your team, then you should accept defeat (at least at work; at home you can do whatever you want on your own code) and move on, gracefully.
9. Don't be "the lone wolf coder." Lone wolf developers hole themselves up in their office or cubicle and only exit to get snacks or go to lunch, eschewing any kind of discussions with other developers. These types of developers don't take feedback, they don't work well with others, and are not good in collaborative team environments. If you see this behavior in a prospective work environment, I would treat it as a big red flag. Chances of you learning something valuable from them are small.
10. Critique code instead of people – be kind to the coder, not to the code. A good rule of thumb here is to make sure that any comments you make in the code should be constructive. Rather than using terms like "Why did you do this here?" you might rephrase it to be more along the lines of "I don't understand what's happening here, could you explain it?" By removing the "You" from the equation it now becomes about the code and not the person who wrote it. This is also a good use for automated static reviews performed by a machine; if there is a stylistic rule or good coding practice that has been violated, having a machine tell you is not the same as a fellow developer.

An egoless environment

After all of this, what then makes a good environment for egoless developers? Being willing to:

• Focus on collaboration and execution
• Be open with your opinions, but once a decision has been made, move on
• Be open to feedback from others
• Be gentle, but truthful, with your feedback to others as well
• Grow and learn, as well as teach and share what you have learned with others
• Roll with the punches

We’re all human with human emotions, so it’s good to keep that in mind when responding to others. If you are feeling defensive about something, examine why before you respond. If it feels like someone is retaliating against you for something you said, take a breath and speak to them privately about it. In short, be open to others, be free with your opinions, be willing to collaborate, and most of all, be aware of your own emotions and where they may be coming from.

Get your free ebook

"The 30-Minute Project: How to improve Your Side Project Game to Become a Better Developer"
at 30-Minute Project