Software developers are people. People who care, people who want to do their very best to make their products better and their customers happier.

I have been fortunate to work on products that are used by millions of people. And almost all the time the changes we make are well received and we get great feedback. There are always some negative reactions but typically those are few and short lived. However, every once in a while a change lands that strikes a nerve with a group of customers. 

I was leading a team who made such a change. We totally re-built the UX of an important part of our product and took away a key bit of functionality. We had good justification for doing this and had data (and graphs!) to back it up. But we also anticipated the customer reaction. We beta-tested the feature, we reached out early, got feedback and telemetry to a point where we felt confident that we were ready to turn it on for everyone. 

And when we did I was shocked not just by the deluge of negative comments but by their vitriol. Some comments were just “This change is disruptive to me and here is why”, but there were many that were apoplectic. My team and I were attacked, accused of being malicious in these changes or just plain bad at our jobs. (In fact, one person even tried to “help” us by describing how git revert works!)

Let me tell you, it hurt. How could it not? I take deep pride in my work and put a ton of effort into it. I want to help and satisfy my customers. I am thick-skinned enough to handle people not liking everything we put out, but I had a hard time swallowing the direct attacks on our motives.

After a bit of self-reflection I realized I have been on the other side of this encounter as well. I may never have angrily emailed a development team, but there have been times when I assumed the worst and held disparaging thoughts towards a team/company’s motives.

To combat this I now actively try to practice the principle of charity.

The principle of charity or charitable interpretation requires interpreting a speaker’s statements in the most rational way possible and, in the case of any argument, considering its best, strongest possible interpretation.

For software, this means assuming the development team has the very best intentions possible behind any change. Assume that they researched and have data. Assume they spent months laboring over the customer impact and made many trade-offs to help satisfy a diverse customer base with varying needs. These assumption may be wrong and that’s O.K. Starting from this point of view will lessen your own anger and allow you to communicate more cogently about why an update has caused you problems.

For example, when Google shutdown their Inbox email client I initially felt very annoyed since I love that software and why wouldn’t Google care about customers like me? Coming from the Principle of Charity allowed me to step outside this feeling and realize they must have valid reasons. To be more helpful, I could write feedback about what are the features of Inbox that were most important to me, how I use them and express hope that they integrate into GMail.

In fact, after the initial set of harsh feedback my team received petered out, we were able to connect directly with several customers and listen to their feedback. Through this positive interaction we made several changes that helped validate the customers problems while still moving the product forward.

The key take away here is that it is 100% fine to be frustrated and annoyed with changes in the software you use. It is extremely important to share feedback with the company/product/team who made it but share in a way that acknowledges and accepts that the product you are giving feedback on is made by actual human people who can be affected by your words. When you do this, you will write feedback that is more constructive and actually more likely to lead to change.