Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Empathy is a Technical Skill

Empathy is a Technical Skill

Key Takeaways

  • Empathy is more than a feeling. It’s a skill that can be learned and applied.
  • Lack of empathy while coding can lead to legacy systems that are difficult to work with.
  • Leaving communication artifacts throughout your codebase can help other people understand your ideas, rationale, and constraints.
  • Empathy can help you identify human bias and assumptions that get built into software systems.
  • Empathy is a deeply technical topic that you can fully explore just like you would a new programming language.


What does empathy have to do with legacy code? A lot more than you might think. Ten years ago, a friend from high school asked me to join his startup (you can listen to our interview on the InfoQ podcast for more on that story). My one stipulation was that empathy had to be at the core of our work.

Over the past decade, I’ve been amazed at how an empathy-focused approach to software development can help pay down technical debt, increase automated test coverage, build trust among team members, and contribute to the overall health of a software system. I spent the first half of my career learning about the deep technical nuances of empathy, and the second half modernizing legacy systems. Now, I’m on a mission to help other technical teams understand exactly what empathy is and how they can infuse it into their daily development practice.

I always love connecting with folks and am a regular keynote speaker at conferences all around the world. My next stop is the Agile Summit Greece in September, so if you’re there, be sure to stop by and say hi!

What is empathy and how is it a technical skill?

In the Encyclopedia of Social Psychology, Sara Hodges and Michael Myers describe how "empathy has many different definitions, some with multiple parts." The fact that empathy has subtypes is a clue that there are a lot of nuances to uncover with empathy, and that it’s a juicy, deeply technical topic. One of the definitions I like best is by Dr. Brené Brown in her book Dare To Lead: "Empathy is...connecting to the emotions that underpin an experience." 

There are two different ways to connect: with your heart and with your head. If you start digging into the research, you’ll find specific definitions describing each approach.

  1. Emotional empathy (also known as affective empathy) is an emotional response. For example, if you see a blooper video of someone getting hurt, your gut reaction is to cringe thanks to the mirror neurons in your brain. Or, when you learn a friend has lost their job, you feel that sadness and loss for them, because you remember a time in your life where you went through something similar.
  2. Cognitive empathy (also known as empathetic accuracy) is an intellectual exercise. This type of empathy is a learned skill. It’s often not as innate as emotional empathy. With cognitive empathy, you gather data on how another person is likely to feel and then purposefully put on a lens and try to see the world from their perspective. Cognitive empathy is routinely taught to marketers, researchers, writers, and UX professionals, but it’s just now becoming recognized as a skill that’s useful for software developers, too.

In her book, Practical Empathy, Indi Young synthesizes six different variations of empathy. Reading her book, which is written for a more analytical audience, was one of the first times I had seen empathy explained for a technical audience, and it was a lightbulb moment for me. According to Young, there are two distinct phases to developing cognitive empathy, particularly in the context of understanding the needs of a customer. The first step is to develop empathy through research, such as listening sessions. Then, once you’ve acquired an understanding, you actively apply this knowledge by improving the user experience.

Empathy is for back-end engineers, too

It might seem obvious that empathy is a skill for customer-facing roles, but what about engineers who might be a step removed from those interactions? The truth is, we write code for people more than we do for machines. That small shift in perspective can have a profound impact. Yes, of course we want the code to compile down into a specific series of ones and zeros that will make the software perform the way we expect. However, we write in compiled languages as opposed to binary, because it’s easier to read and understand. When we think about the people who will encounter our work, we are practicing empathy.

A good way to get started practicing empathy in your daily development is to think about yourself encountering the code a year from now after you’ve forgotten the context. Think of a time when you discovered some code that really frustrated you, and connect to that feeling. Then, think about activities you can do now that will save yourself from feeling that frustration and pain later on. Can you leave an artifact of your thinking that can help you build that context back up quickly? Connecting to this underpinning emotion can quite often provide the intrinsic motivation that turns a rote task that we’re "supposed to do" such as writing an automated test, updating the documentation, filling out complete commit messages, and writing descriptive names for classes, functions, variables, etc., from things you do just to check a box, into activities that you crave because you know it will save you frustration in the future.

Extending empathy beyond your team.

Now that you’ve thought about yourself, can you think of the people on your team? Your product owner? Your customer success manager? Your end user or client? This process of being mindful of opportunities to seed our software with artifacts of your thinking can go a long way to keeping your codebase healthy.

Can you think about underrepresented populations who might be negatively impacted by your assumptions? Humans use heuristics and mental shortcuts all the time. We’re built with bias. This in and of itself isn’t necessarily a problem, but when we program software, it’s critical that we understand and recognize how the bias that we build into our creation will impact others. Karen Hao at the MIT Technology Review has done some excellent reporting how bias in deep-learning software can "perpetuate injustice in hiring, retail, and security, and may already be doing so in the criminal legal system."

Think like an archaeologist

So, what are we to do? Now that we know empathy is important, how do we start adding it into our workflow? Archeology and anthropology can give us good metaphors for what it’s like to work with software that we didn’t write ourselves. If you’re attempting to reconstruct someone else’s viewpoint, but you don’t have direct access to them, you’ll need to rely on two critical components: artifacts and context. The same applies to software.

In a legacy system, we often don’t have access to the developers who initially wrote the code. So instead, we need to look at what they’ve left behind — their artifacts. Just like how pottery, skeletons, coins, foundations of buildings, and writing can help us figure out what someone’s life was like in the distant past, we can use those principles in software, too. The question to ask as you’re going about your daily work is, "Am I leaving durable evidence of my thinking that will help someone in the future?" That might be someone else after you’ve left for another role, or it could be your future self six months from now after you’ve forgotten the details of what you were working on.

The second critical component is context — understanding how an artifact fits into a situation. In software, this is leaving evidence of why a decision was made. Learning to find ways to sprinkle your rationale throughout your code, through good commit messages, pull request comments, architecture decision records, and more. The practice of leaving communication artifacts in context is rooted in empathy and a critical skill for modern software developers.

Can we write an empathy algorithm?

The most logical and analytical among us will naturally see a messy and complex emotion and want to streamline it into something categorical and clean. We’re human and this is a natural way to navigate the world. As Dr. Brown notes in her book Dare To Lead, people always crave certainty. She describes how over the years people have approached her with the idea of an "empathy decision tree" to help them navigate complex social situations, and it just doesn’t work. "The only solution is to connect and pay attention," she says.

While an empathetic response library isn’t necessarily a useful effort, I’ve found that you can employ an algorithmic process to help you become more mindful of ways that you can leave good communication artifacts in the code you write. When I slowed down my own mental process, based on years of training in using cognitive empathy to create content, I was able to see six distinct steps, which I’ve outlined in the paragraphs below. I was inspired by other frameworks, such as Test-Driven Development, which can be distilled into the mnemonic "Red, Green, Refactor." Similarly, this process of Empathy-Driven Development can be simplified into two parts: Audience & Action. Let’s dive into each in a little more detail.

Know your audience

If we go back to Indi Young’s work, we can’t apply empathy until we have a deep understanding of another person’s experience. In order to get there, you need to figure out who you’re connecting with, think through the context that person is in, and then discern what that specific person needs in that context. Listening sessions, which are described in detail in Young’s book Practical Empathy, are a key tool to uncovering the underlying reasoning, reactions, and guiding principles of different people.

  1. Identify Individuals — Think about all the different types of people who will be impacted by the code you write. Some common groups include team mates, end users, customer success managers, product owners, executives, even your future self. Then, imagine yourself developing an artifact for a single person within that group. In the marketing world, this is known as audience segmentation and it’s the foundation of any good communication practice.
  2. Consider Context — Once you have an individual in mind, consider the context they’re in. Are you only thinking about a desktop experience, or is your end user someone who will be constantly on the go? Are they in a quiet space or distracted regularly as part of their role? Thinking through these scenarios can help you write code that’s more understandable.
  3. Define Needs — What does this individual in this context need? If you don’t know, this is the time to gather data. Too often, we make assumptions in this phase and that can lead to larger problems down the road.

For example, you might start by thinking about the group of Customer Success Managers that work on the floor above you. Then, you imagine one person in particular, Jaylen, who was kind enough to sit down with you for coffee last month for a listening session. You remember Jaylen saying that part of what makes their job stressful is that they’re rated on how quickly they resolve customer inquiries, but that the documentation quickly becomes out of sync with the features in the codebase. When they point a customer to a response that’s out of date, the customer comes back frustrated and Jaylen has to spend extra time communicating with the customer to resolve the issue. Jaylen is frustrated because it impacts their compensation. What they need is confidence that the response library they’re using is accurate.

Take action with proactive problem-solving

The next step on our applied empathy journey is to imagine all the ways in which we can make life better for Jaylen. We’ve connected to the underlying emotion of frustration behind the experience. That’s great. But what’s even better, is to work with Jaylen to find ways to prevent that from happening in the future.

  1. Best action — Given the situation, what’s the best action you can take to meet the needs of the individual in this context? This is where you dream big and think about what you would do if you had all the time and money in the world. You won’t often get to implement all of your best action, but that’s where the next step comes in.
  2. What’s feasible? — Given your own limitations of time, money, knowledge, etc. what’s something you can implement now that will help make a positive impact? For example, maybe you don’t have time to implement anything, but you can come up with a list of ideas and send them to Jaylen with the question, "Would any of these be helpful to you?"
  3. Create artifacts — Running through this process will inevitably generate ideas that you’ll want to preserve. Include these communication artifacts in your definition of done. Common communication artifacts include: commit messages, refactoring for legibility, documentation, creating an issue or reporting a bug, making a note in your engineering log — all sorts of things.

Developing empathy requires practice

If there’s one thing you’ve learned about empathy from reading this article, I hope it’s that you’re starting to think of it more like a skill, and less like a magical trait that you either possess or you don’t. Acquiring new skills can be intimidating and scary when you’re just starting out, but don’t let that stop you from working at getting better. Adopting a growth mindset and recognizing that you are capable of building empathy is critical. Negative self talk, such as "I’m not good with people," can really hinder your progress. So, where do you start? Here are three resources that I recommend:

In her book, Dare To Lead, Dr. Brene Brown lists five skills that are important for building empathy:

  1. To see the world as others see it, or perspective-taking
  2. To be non judgemental
  3. To understand another person’s feelings
  4. To communicate your understanding of another person’s feelings
  5. Mindfulness

Young outlines a process of what she calls "listening sessions" to help you develop the skills that expert qualitative researchers, journalists, psychologists, and other professions that require this process have honed. Some of her tips from Practical Empathy include:

  • Start with a broad topic
  • Use the fewest number of words possible
  • Avoid introducing words the speaker may not have heard
  • Try not to say "I"
  • Be supportive and present
  • Resist the urge to demonstrate how smart you are
  • Neutralize your reactions

Still, another resource that’s already popular in certain developer circles is Nonviolent Communication by Marshall Rosenberg, where he outlines a framework in two parts:

  1. Expressing honestly
  2. Receiving empathetically

He recommends developing practices such as:

  • Ask before offering advice or reassurance
  • Listening for feelings and needs
  • Reflect back messages that are emotionally charged
  • Empathize with silence by listening for the feelings and needs behind it

Of course, these suggestions are just the metaphorical tip of the iceberg. Empathy is a deeply technical topic, after all. There is a treasure trove of very deep and specific research, tools, and advice to help you learn and apply empathy throughout your work. Focus on these skills and make a commitment to become curious and practice empathy every day, just like you would around a traditionally technical skill like learning a new programming language. In the beginning, it’s awkward. Over time, it becomes intuitive. Will you make mistakes? Of course. You made mistakes when you first learned how to code, but you didn’t let that stop you did you? Empathy, like software, is a deeply technical topic that can challenge you in the best way while making your life richer and more rewarding. And isn’t that something worth exploring?  

About the author

Andrea Goulet is the CEO of Corgibytes, a software firm dedicated to making existing applications more stable, scaleable, and secure through technical health. Named by LinkedIn as one of the Top 10 Professionals in Software Under 35, she’s the founder of LegacyCode.Rocks, a sought-after keynote speaker, and is easily recognizable by the JavaScript tattoo on her wrist.


Rate this Article