Writing Software with Empathy

I began my professional career in 2012 as a product specialist at AppNexus, helping customers use the AppNexus platform to buy and sell online advertising. A nascent startup at the time, AppNexus was growing quickly in many different ways, so needless to say my team and I fought through some very tough times. I remember when we had to tell customers who observed a $1000 overspend on a $10 ad campaign that the overspend was expected behavior given their setup, even though the Console made no attempt to warn them in advance that this could happen. Then there was the day when the Console was rendered unusable because of a bad code merge. Another time, I was woken up at 2am by a major customer because a bug erroneously disabled paid ad traffic on one of the most visited web portals in the world.

This was my life for one-and-a-half years until I moved into the world of software engineering. When I made the pivot, all these experiences stuck with me. Having to work with customers through thick and thin, I developed empathy for their situation. Accordingly, my mission in moving to software engineering was to solve the customer problems that I was triaging and escalating as a product specialist. I remember thinking to myself (rather naively) that I would build software to the point that the issues my team encountered would become a thing of the past, at least for the software within my control.

Being fully immersed in the land of customer service, however, made it easy for me to lose sight of the big picture. As I’ve come to learn, developing software is hard. A fix for one customer may break another. Features that are important to some users may alienate other users. Developing features in parallel is no easy feat when touching the same codebase; it is so easy to get crossed up. Not to mention that engineering resources are always a scant commodity and that engineers require extensive focus time which also tends to be in short supply.

That being said, for many engineers I’ve worked with and led, the engineering life is all they’ve ever known. When fully immersed in the engineering world, it’s all too easy to dismiss customer pain as expected behavior or to deploy new software on a Friday because it works and compiles, so what’s the harm? Over the years, I’ve made it a point to imbue the engineers around me with strategies to think about the big picture. For example:

• Try to think of how a customer may use features in your product, rather than just how they were intended to be used. Do the features align with the customer’s workflow? Are there ways they could use the features that are inherently self-destructive?
• When building out error flows, pretend to be a customer with no knowledge of the internals of your product. Do the error messages make sense when seen independently of each other? How easily would they be able to take the necessary corrective actions? Are there ways that the error messages could be misinterpreted?
• When introducing a code change, take the time to fully understand how it will impact the rest of the system. What other features rely on the code, beyond the feature for which the change is intended? Would your code change affect the business logic for those other features? Think of how many customers depend on all those features. Use this to assess the risk-level of the change, bringing in additional code reviewers for high-risk changes.
• Never assume that your code will work when deployed to production just because it compiled successfully or your tests passed. Regardless of how much you attempt to cover your bases, mistakes do happen. Be present when your code is deployed and do a sanity check to make sure that everything behaves as you expect.

Don’t get me wrong, mistakes do happen. As a developer, I’ve had my fair share of those too. We should not let the fear of failure prevent us from moving products forward. But when we take the time to understand the big picture, everyone is better off.