Egoless Programming

This post was originally written for a Tableau internal development blog.

In the last few weeks, there were some arguments and some upset developers in our team. There were bugs and fixes that upset the people across the scrum teams that worked on them; a few people were mad at each other for the way the others acted. Some of the developers had attached a portion of their feeling of self-worth with the code they had written and felt attacked by others changing it even though they acknowledged the code had problems. With communication between the parties directly involved and some discussion and solution brainstorming moderated through third-parties, the issues were resolved. No one involved is upset anymore, everyone learned how to better work together, and the features that had the bugs are working better than ever before.

Witnessing this unfold reminded me of a concept one of my mentors in college taught me (but sadly was never addressed in any of my classes) that we can all learn from: Egoless Programming.

The idea is that programmers must fight the natural tendency to treat their programs as part of themselves, and therefore to reject all criticism. Rather, they should do their best to treat their designs & implementations as objects independent of themselves, and to view criticism dispassionately on its merits. It's a spiritual discipline that we all fall short of, but that's worth attempting.
-- http://c2.com/cgi/wiki?EgolessProgramming

The concept of Egoless Programming was originally introduced by Gerard M. Weinberg in his 1971 book, The Psychology of Computer Programming, but the ideas involved are just as useful and relevant today as they were 45 years ago. Weinberg introduced 10 guidelines, all of which relate closely to the Tableau Core Values or our Dev Practices:

1. Understand and accept that you will make mistakes. Everyone makes mistakes; none of us are an exception regardless of level of experience. By accepting this truth, we can each more easily implement the rest of the guidelines. By being honest with ourselves, we take a necessary step toward embodying our Core Value: “We Are Honest.” This guideline also acts as a reminder of the value of rigorous testing; since there will be mistakes, we need to be sure we are vigilantly looking for them. By testing, “We Build Great Products.”
2. You are not your code. When we create something, we are often proud of it and attach to it. That clever method I wrote might feel like a child. That great interaction design might feel like a close friend. Those things aren’t actually our children or friends though. If something is wrong or incomplete with the thing we made, that doesn’t mean we are broken people. We all make mistakes. We can be proud of our successes and we can also be proud of learning from our mistakes. By not attaching ourselves to our creations, we can work with others to make them better.
3. No matter how much "karate" you know, someone else will always know more. You may be the expert in an area, but there is always more to learn. Getting caught up in the arrogant concept of having already achieved greatness and resting on our laurels disrespects those around us. Everyone should always be asking for assistance from our teammates because they can always teach us things and we can always teach them things. “We Work As a Team” and “We Respect Each Other” are both tightly coupled with this guideline because the willingness to teach and learn shows how we value our teammates and what they bring to the team.
4. Don't rewrite code without consultation. Since you can always learn from others and everyone makes mistakes, we should always get feedback on our work as soon as possible and every step of the way. We should collaborate on designs and test plans (e.g. Should we be doing this work? Is this the right approach?), then collaborate on the changes as we make them (e.g. story decomposition, code reviews), and finally collaborate on release and defects (e.g. Does this design really work with the other features? Should we turn on this feature flag now? Is this defect worth fixing now? Are we missing some sort of documentation or example so users will understand this?). On my teams, we seek out experts across the company to review our work at all of these steps to be sure we are building the best features we can. The “You are not your code” guideline is incredibly valuable here in being able to accept feedback.
5. Treat people who know less than you with respect, deference, and patience. Our “humble smart” attitude (part of the “We Respect Each Other” Core Value) makes this one easy for us to follow. Since we can all learn from each other and “We Work As a Team” it should be obvious that we should treat those who can learn from each other with respect.
6. The only constant in the world is change. There will always be a new thing, good or bad, that affects our work. It could be new knowledge about our users’ needs (remember “We Delight Our Customers”) or a new technology that enables us to move in another direction or a new defect in a third-party library we rely on. Whatever these changes are, we always need to be able to adapt to the changing environment we work in. Our agile development practices enable us to be adaptable in this way.
7. The only true authority stems from knowledge, not from position. Dev Leadership having embraced this idea is core to our agile development practices being implemented and being successful. No one can know everything deeply, especially someone being pulled in as many directions as our Strategy Area Leaders at the tops of our hierarchies. The teams doing the work can and do know their areas deeply; they are the authorities on their areas because they have that knowledge. The people in higher positions in our organization respect the authority of the people “on the ground” by taking our feedback about which, how, and when to implement and release features.
8. Fight for what you believe, but gracefully accept defeat. Since we are all learning from each other and collaborating on our work, we all gain deep knowledge in some areas. When you are an authority in an area, you should fight for your beliefs in that area. Sometimes your idea won’t be the best one and won’t be chosen for whatever project is being worked on. Since “You are not your code” and “We Respect Each Other” you shouldn’t be a sore loser when your idea isn’t picked; your contribution to the discussion helped everyone learn. If the environment changes and your idea becomes the best one, you also shouldn’t say things like “I told you so” because of our respect for each other and what we learned by going the other way for a time.
9. Don't be "the guy in the room." Since we collaborate so much to make our products great and learn from each other, you can’t “go dark,” working alone on something for extended periods, and still be an effective contributor. If you aren’t collaborating with your team you aren’t respecting the feedback they would have for you.
10. Critique code instead of people--be kind to the coder, not to the code. Finally, we need to always remember to respect each other when we are critical of others’ work. Some of our teammates will be at different levels of attachment to their work (Everyone makes mistakes and sometimes those mistakes are in not following these guidelines such as “You are not your code.”) so we need to be sure to not be attacking them when we are giving feedback on their work. By being positive in tone and focused on the work we are reviewing instead of the person who did the work, means we are much less likely to upset the person who did the work even if they are strongly attached to it. Not being kind to the work itself is a sort of test of that product and lets us discover ways to make the product great.

By striving to follow these guidelines we can all help each other build great products now and in the future.

More sources:
http://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
https://jaxenter.com/is-egoless-programming-still-relevant-119621.html