Empathy-driven development empowers developers to create software that truly understands and serves users' needs. This talk explores practical techniques for integrating empathy into the development process, leading to more intuitive, user-friendly applications. Learn how cultivating empathy can foster collaboration, improve code quality, and ultimately enhance user satisfaction. Join us to unlock the transformative potential of empathy in your development journey.
Empathy Driven Development
AI Generated Video Summary
This Talk explores empathy-driven development in software engineering, emphasizing the importance of understanding and applying empathy in code reviews, communication, and team collaboration. It highlights the benefits of empathy, such as personal growth, effective communication, and high code quality, while cautioning against excessive empathy. The Talk also discusses building empathetic teams, conducting empathy workshops, and practicing empathy in interviews. It addresses language barriers, handling engineers, and the role of AI in fostering empathy.
1. Introduction to Empathy-driven Development
I'm going to be talking about empathy-driven development today. How can you apply empathy as a developer or in your development process? Let me introduce myself. I'm Anjula Dubey, a Technical Delivery Lead at Vanguard Europe. I'm also an organiser at React India and JSConf India. You can find me on Twitter as Manjula underscore Dubey. Are you here to learn empathy or apply it to your development teams? Any technical leaders? There will be useful insights for you.
So, hi everyone. I'm going to be talking about empathy-driven development today. Maybe this is the topic that is not spoken a lot about and that is why I'm here today, building a software with human touch and how can you apply that. How can you apply empathy as a developer or maybe in your development process? So, maybe we are going to look at that.
But before that, let me introduce myself. I'm Anjula Dubey and I'm a Technical Delivery Lead at Vanguard Europe. Vanguard is an investment firm. Just for your knowledge, it's a company from US. I'm also an organiser at React India and JSConf India. On Twitter, you can find me by Manjula underscore Dubey. So, if you want to ask me some questions after my talk, you can also reach out on Twitter.
Cool. Before we move on, quickly, you can raise your hands up. Why are you here? Maybe to learn empathy? I guess all of us know about that. Yeah. You can Google it and you would know. Are you here to apply empathy to your development teams? Yes? Okay. Any technical leaders here? Tech leads? Team leads? Maybe a lot of useful insights today that you can gather and go back and apply to your team.
2. Understanding Empathy
Empathy is the awareness of the feelings of others. It means putting oneself in someone else's shoes, comprehending their emotions, perspectives, experiences, and responding with sensitivity and compassion.
So, just a simple definition, of course. All of us know what empathy is. It's the awareness of the feelings of others. I mean, all of us know, very simple. But how do we apply it? So, the definition says that you put oneself in someone else's shoes, right? And to comprehend their emotions, perspectives, experiences, and how do you respond with sensitivity and compassion? But does it really literally mean wearing somebody else's shoes? No, of course not, right? What does it mean? Bryn Brown said that you should be able to see the world as others see it, or maybe not be too judgemental about your junior developer or a senior developer, or maybe understanding other feelings. We'll see that in our coming slides.
3. Applying Empathy in Development
The definition of empathy-driven development means focusing on human behavior in the software development process. Applying empathy in code reviews and discussions is crucial. Instead of blaming and shaming, try to understand the context and find ways to improve. Avoid accusatory questions and use a more objective tone. Stop criticism and focus on what the developer could do. Emphasize understanding and provide constructive feedback.
So, the definition of empathy-driven development means that you focus on the human behavior in the software development process. And that will help you foster trust, transparency, and also build robust software, right? And how you apply it in your development process, we'll see it later.
So, as said, empathy is for engineers too, right? You agree with me? Yeah? How many of you have dealt with legacy code here? Come on. Yeah? I mean, me too. Yes, I started my career as a developer, and all of us go through the legacy code.
Now, again, a question. How many of you saw the code, you joined the company, and you were like, Oh my God, who is this idiot who has written this code? Come on, let's be honest. Yeah? I mean, that literally is a wrong behavior. How are you applying empathy here? We should stop doing that. We should stop blaming and shaming because that stands against the principle of empathy. Right?
What you should do instead? Swap the blame on her. Come on, let's. You don't know how and when that code was written in what scenario. Was there a strict deadline? You know, that developer wrote the code, but now he's gone. And now you are here to make it better, right? So why are you even, you know, blaming that developer? Start to think about how can you make it better? That emphasizes you as a developer to focus on empathy. Right?
Now, how often do you, when you do a code review, you start with a question. Why didn't you? Why did you? Let's be honest. No? Everyone, okay. We have some hands up. I think that's, again, a wrong behavior. It might hurt somebody because somebody who is a junior dev who has just joined the company, and you're like, why did you name this variable? Or what is this code doing here? What would be the correct way to do it is, could you please explain me what are you doing here? That is more not accusative, but it's more objectives. So stop being accusative, stop being accusatory in your conversations, stop asking direct questions, which might hurt others. And these are the small things which you can start applying, right? As a developer. I mean, it doesn't take a lot of effort from us. It's just the tone. Right?
So let me give you some things that we could apply. I mean, stop criticism, focus more on what that developer could do. Like start with, could you, you know, that emphasizes a lot. Maybe also first understand that who the developer is. Maybe you writing the comments in your code reviews, because you're more senior.
4. Applying Empathy in Code Reviews
But you know, the code is written by a junior. So be more clear in your feedback. Encourage and recognize good parts. Avoid turning pull requests into chats. Share guidelines on being empathetic while communicating on pull requests. Remember that empathy is not just for code reviewers, but also for developers. Care about code quality and consider future developers. Put comments in challenging parts and thoroughly test before submitting PRs.
But you know, the code is written by a junior. So also understand the perspective from where is it coming before you write your comments. So be more clear, like, you know, articulate your feedback very clearly in the code reviews as well.
Encourage and recognize, like, let's say you see something good, right? Just put a comment. That was really good part. Because that kind of make sure that you are encouraging that developer. Right? I mean, I have seen in my past companies, the whole pull request changed into a chat. Right? It was like 40 messages on top. And you know, then the developer is defending. Don't do that. I mean, this could have been as if I'm a developer, I could have just gone to that person, sat with that person. And you know, I could do that. There's no need of doing like 50 messages on that pull request. You're not being empathetic there.
So these are some of the guidelines. I mean, of course, I'm not going to just go and read all of them. I'll share the slide later and you can read it. But it just gives you how you can be empathetic and apply these, you know, while you're communicating on pull requests. These are very small things. And you as a human don't know how you might hurt others. So just maybe, you know, before you are even writing, just make sure you're being more empathetic. So empathy is not just for the code reviewers here. You as a developer, because you're writing the code, you need to be empathetic as well.
Because someone else, as Armin rightly said in his previous talk, code quality, right? If you write with an attitude of not caring who's going to be the next developer in the company, you're just going to write, right? But if you're going to care, okay, this is something hard bit. Let me maybe put some comments. Let me maybe name the variable, you know, in a more manner that the other developer, when he comes and sees the code, he's able to read or he's able to understand what's going on. So it's also part of us who are writing the code. Which means if you see any part in your code, which is more challenging, just maybe put a comment, right? Some extra comments also for the future leaders so that they understand what's going on in that part. Very, very important. Like we as developers, make sure it is thoroughly tested before you submit your PRs.
5. Balancing Technical Requirements with Empathy
Don't mention 'it works on my machine'. Proactively document complex tasks. Balancing technical requirements with empathy. Start a debate on requirements. Give thought to commit messages, pull requests, file and test names. Communication is key. Be mindful of tone in communication artifacts. Soften communication, even with juniors. See the bigger picture.
And don't mention that, oh, it works on my machine. I don't know. So, you know, be very careful. How many of you here have proactively documented something that was little, little complex for you? So keep doing that. I mean, there might be not a task assigned to you separately, but do it because, you know, you are being empathetic in that behavior because, you know, this is a complex bit. Let me document it. Now, by documenting, what are you doing? You're making it easier for your future leaders, right? You're thinking about future developers. So start doing that. Balancing the technical requirements with empathy. Sometimes there might be, you know, some requirements which might go against empathy. So start a good debate on that. Maybe it is with your product managers, designers. You should do that. Commit messages, pull requests, naming your files, naming your tests. How many of you think, I mean, do you just put up something that comes to your mind? No? I mean, a little thought through, right? And that really helps because these are the small things that you start applying and then you may be unintentionally, you're not even thinking about it, but you know, maybe you're doing something wrong. But when you start giving too much importance or a little bit importance, you start creating that effect, right? So those are all fundamentally about communication. And in all these aspects, basically what we are trying to say is communicating the tone, right? So that's how you see that communication artifacts is one of the important artifacts in development phase. These are some of the stuff, verbal, nonverbal, maybe writing an emails, right? Right? Be a little soft, not too harsh, even on pull request or maybe a junior. So a lot of things comprises this. This kind of gives you a bigger picture.
6. Benefits and Importance of Empathy
How does empathy benefit you as a developer and as a team? It leads to personal growth, effective communication, reduced stress, and a positive team environment. It also results in high code quality, job satisfaction, innovative creativity, and a product that users love. Empathy is important because it adds value, fosters a positive culture, and builds a brand image. However, it's essential to be aware of the potential negative side and how it can harm you.
Now, how does it benefit you, like me or you as a developer? Of course, personal growth, effective communication, reduced stress, positive environment in the team, good performance. Of course, when you're dealing with good code quality, you're having that collaboration between code reviews. Good in a good way. You know, all that benefits you.
How does it help as a team? As a team, of course, there's high code quality, effective communication. There's more job satisfaction. There's innovative creativity. A lot of things come. So these are the small, small things, but still adds up the way you communicate within your team. And of course, for the organizers, organizations, it is more like, you know, building that positive culture, brand image, better attention rate. This is something very important. Yes. More inspiring leaders. And most important, you're building a product or a software that users love to use. Right. So, of course, you're doing all that work under a nutshell, being a good developer, being an empathetic developer, but that is adding value. Right.
So why is it important? Like, generally, you know, Andrea Gollett, you can Google about her, but she advocates a lot about this in her own company. She gives talks. Why it's important? We'll go through responsibility-driven development, DDD. You see the last reference, empathy-driven development. Why is it important? You are caring, you're considering, you're connecting with your people. And that's really important for you to run in an organization or a team. Right. That's the base. That's the foundation. But everything has a negative side. Right. How can it harm you? Right.
7. Harmful Effects of Excessive Empathy
Too much empathy can be harmful. Forcing your experience onto others is not correct. Apply empathy in an effective way by fostering non-reactive empathy. Understand that most of the time, people just need a compassionate response or help. Effective empathy involves thoughtful and compassionate responses.
How can it harm you? Right. How can be empathy hurtful? Too much of empathy is really bad. Like, for example, you have a developer, let's say, right. And you're kind of forcing your experience onto him. That's not correct. Because you're forcing that person and putting in a situation where he or she is not really comfortable. Right. Which means you're not responsible for how other people feel. So apply empathy in an effective way. Right. Foster non-reactive empathy, which means you can care about that person. You can help. For most of the part, that person doesn't even need the help. Most of the part, that person doesn't even need that you feel their pain. You know, they just need some compassion response or your help. So rightly said, apply it in a more effective way. So effective empathy is a skill that goes beyond understanding others' emotion. It involves thoughtful and compassion response.
8. Building Empathetic Teams
Imagine a scenario where a team member is new to a complex technical task. How can you make them comfortable? Approach them as a leader, actively listen, offer help, and provide resources. Also, ask open-ended questions to understand their feelings and suggest solutions. Building empathetic teams is crucial for a positive work environment and successful collaboration.
Okay, so everyone can read here, I guess, what's written. Imagine a scenario where one of your team members, let's name Chris here, is working on a complex technical task. And Chris is relatively new to this technical tech stack, okay. He's just come, he's just joined, maybe the tech stack is Kotlin. And he has some challenging problems and he's trying to implement it. What do you think? As a developer, what would you do to make this person comfortable?
Sure, yeah. So maybe approaching that person as a leader, maybe proactively checking in, that if he's fine, or you do, you need some help, very actively. If he's fine, or you do, do you need some help? Very active listening, because that really matters, he's very new. You need to keep a constant check on him and be an active listener, is he facing problems, what he needs? Does he need some resources for him to be comfortable? Does he need to do a pair programming? So it is something that is also not on the leaders, but also on the peers, right? So yes.
Now, again, let's have an example that a team is working on a critical project. And there's someone who is technically brilliant. And he has now a deadline to finish this project. And you would also appear to him. But you have a little less knowledge with that project. But you're also in his team, how would you do? How would you make sure that Alex is not feeling overwhelmed and stressed at the same time?
Okay, let me see. So maybe here, what we can do is ask Alex with an open ended questions, ask him, okay, Alex, what do you feel? Should we shift the deadline a little? Or maybe we should approach the product manager. So you as a team, are being a little empathy. You're having that empathy within you and asking him this questions, right? Even though you're peers, you're not directly responsible to deliver this project. But you know how to make the other person more comfortable. So these are some of the questions that of course, you might have in your team as well, somebody is struggling, make sure you are kind of going through these questions, or maybe you know, making them more comfortable by sharing your own experience that okay, I was there in a certain situation, but making sure don't overshadow your feelings with your experiences. So we went through a lot of stuff already at the end, what are we doing here? We are kind of building that empathetic teams, right? And this is really, really important. And this is one of the topics that nobody really talks about. But at the end, if this is not really solid in your team, you can't work with your team members, there always be conflicts, there'll always be stress in the team. Nobody would be accountable. And nobody even be bothered to ask you, how are you feeling today? Do you want me to take care of something? Right. So that's really important. So we don't code just for building our products. Remember this. We also code for our future humans, right? That is really important. So this is one of the things that you should always have as a developer, even while you're reviewing, even while you're onboarding a new member, any practices or any processes that you're doing.
Empathy Workshops and Interview Practices
So as an organization, start focusing more on having empathy workshops. Treat empathy as one of the technical skills. How can we be better interviewers? It all comes down to how you practice it. Having someone as a shadower in interviews can be helpful. Ask the audience who's doing conscious interview practice with a focus on empathy. There will be non-empathetic situations, but giving feedback always helps. Using AI for text messages may not contribute to empathy as it lacks personal feeling.
So as an organization, start focusing more on having empathy workshops. Like, if it's not happening in your organization, go back and tell them, let's have some workshops or trainings. And you learn one important technical skill, although it was not a technical talk, but treat empathy as one of the technical skills. And thank you.
Yeah, I think we have a first question, which we actually can expand a bit on. I wish to see more empathy from interviewers. I think that's like quite an interesting problem, because the interviewer also wants some empathy from the developer that resources are time constrained. And so in that case, how can we be better interviewers? But how can we also make sure that we transfer that if it's not going to work out in an empathic way, but we don't waste each other's time. Is there any solution? I think this is really a good question. And I think it all comes down from the organization, how you really care about it. I mean, even as an interviewer, like, you know, I'm interviewee as well, it all boils down to an aspect that, you know, how you practice it, right? If you don't practice it at all, of course, you will not be, you'll not even care about it. But if you practice it, and it's really important in your organization over a high-performing team, like some organization, maybe they don't really care. They, all they care about it is, you know, building a high-performing team, no matter what. If you're talking about practicing this year, do you mean like, just practicing interviews as an interviewer internally with your team members? Yes, maybe having someone also as a shadower who was seeing how you're doing it, maybe you are doing it better because you are already there in the organization from very long, you're doing it. And you're also having a shadower in your interview who's seeing it, how you're doing it. So I think that really helps. Okay, so maybe let's quickly ask the audience, like who's doing like conscious interview practice with a focus on empathy? Oh, one person there. We have one person there. So maybe the rest of you can bring it into your companies going forward. Because, yeah, that's another complicated question, very philosophic. How do we react to non-empathic situations? I think, I mean, there are gonna be non-empathetic situations. It's not a good world. Of course, there are good and bad sides. There are good and bad people. Some people understand, some people don't. I think it's very, as I rightly said, that it's very important for you, even if you are in that empathetic situation, maybe just come down and go to that person later on and just tell them that this is something I felt bad and you could have improved. Because giving feedback always helps and that person would go back and maybe, you know, think upon it and try to apply it. So I think it's really good to go back and give that feedback later on. Okay, and if you talk about giving feedback, I think we all still, like a lot of us, are working remotely, and some people might use AI to write like their text messages. So is that helping with empathy? Because the AI will stay neutral in their tone? Or is it like totally unempathic because it's like putting everything into like a different voice? I think empathy is all about you, your feeling.
Empathy in Language Differences and Pull Requests
AI cannot decide. It's purely individual. Language differences can make it harder to be empathic. Team building activities and workshops can help overcome language barriers. Design workshops to improve empathy in pull requests. Use polite language and provide clear explanations. Earlier feedback in the code development process is better.
I mean, AI cannot decide. Of course, it will give you answers, but it's your feeling. And, you know, somebody cannot decide on how you would behave to someone or someone's behavior or, you know, to somebody else. So I think it's purely that comes from within an individual. And I would not rely on AI, to be honest. Yeah.
Maybe we can expand this question a bit, because there's also going to be language differences where a lot of people whose first language is not English, and then they start need to communicate in English. And they just, it's just like much harder to be empathic in another language. Do you have like recommendations there?
Sure. I think, I mean, in my company, we practice a lot. I mean, we have diverse culture, people coming from different regions of Asia, Europe, but we do a lot of team building activities. We do a lot of empathetic workshops together with our Scrum Masters. I think it's really important to have, I mean, languages, of course, a barrier, but, you know, everything doesn't rely only on language, right? You could have some team building together or maybe, you know, some sort of workshops or trainings where you put your feedback and, you know, you kind of articulate it together and see how you could improve. So I think it depends. Of course, there is a barrier, but you can have certain workshops and trainings that would really help.
Absolutely. And how would you design a workshop to, for example, improve being more empathic in pull requests? It's a good question, I think. So in my company, I think I'm working here for almost four years now, we built a full designed, you know, documentation. And these were built by initial engineers, like how to act when somebody is kind of on boarded, maybe, and, you know, you're reviewing a pull request. Language to use, for example, just like I mentioned that, you know, instead of starting your questions with why, you know, having that practice of putting it, could you please change it to this? Or maybe, you know, instead of asking that, why did you do this? You know, be more polite, and could you please explain me what this bit is doing? So I think we had a general practice documentation that we as engineers used it. Okay. And it's really important to build it if you are more... So there should be documentation how to read these? Yes. I think there's something called like conventional comments for code reviews, are you using that? Not really. I think we have a lot of different experiences in the team. We have a lot of juniors, we have way too much seniors. So it's really sometimes become difficult to apply that. But yeah, I mean, it's a good thing to apply. Yeah. And while we're talking about pull requests, are they actually like the most empathic place to give feedback? Or can we try to give that early on the code development process? I think earlier is better.
Handling Engineers and Empathy
Don't make it a chat. The good way is for the developer to go back to the one who raised the pull request and sit together to go through the code. Empathy is not directly proportional to years of experience. It goes both ways. If a junior dev is empathetic, they'll get a positive answer. Dealing with engineers who are not receptive to feedback involves actively listening to them and reflecting back on their behavior. Being empathic doesn't mean being dishonest. It's about being honest and trustworthy.
Just like I said, don't make it a chat, like don't make it a 40 lines of defending yourself. And then again, the senior developer is writing comment. I think the good way here I see is that developer goes back to the developer who has raised the pull request and kind of sitting together and go through the code. I mean, I wouldn't want my PR to have 100 comments. That would be horrible and take a lot of time to fix.
Exactly. You mentioned like senior developers and junior developers. How much is like empathy actually a bit of like growing to another role? And how much should it be like a formal requirement? Because I must say, I didn't really read empathy as a bullet point for like, oh the next level software engineer, you need like that level of empathy. Should we introduce something like that? Should we fight for something like that? Also, like what are the different expectations of empathy in like different roles? Because in the end, we're all humans as you started with. And I would expect all of us to show like the same level of empathy, hopefully, and not necessarily say, no, you're a senior software engineer, now you need to be more empathic. But like... Yeah, you answered it already. So I mean, we are different humans, and we have different experiences. But empathy doesn't mean that it directly is proportional to your years of experience or something like that. I think it is both ways, right? If a junior dev is empathetic as well, so then you'll get the positive answer. But if something starts in a more negative way, of course, the person is going to react negatively. But now he has a control, because he's a bit senior, you know, he can come down and maybe go back later and tell that behavior that, okay, you know, you could have done it a little differently. So, of course, experiences helps, because you know, if you have experience, you know what's going on, and you can be a little calmer at that moment and go back and then evaluate what really happened.
How do you work with engineers that are not receptive to feedback? And how do we handle empathy versus accountability? So maybe like, what do we do if empathy fails us? So I've worked with engineers like that in my team. Yes, where people are not at all receptive. They feel very superior about themselves. And I think the best way to deal with them is for you to listen actively what they have. Because if you become a person that is commanding them, they will never listen. It's more for them to, you know, for us to listen what they really think and why are they being so negative about any of the behaviors. And then reflect back, like you as a manager or you as a team lead or tech lead can go back to them and tell them, this is what you are showing up to your juniors. And this is not really good. Because if you don't actively listen to them, they become really aggressive. So we have like 10 seconds left. Maybe one last question. Does being empathic also means like you sometimes need to be not honest or is there a conflict? I think it's all about being honest. It's all about being that trustworthy so that there is just a mirror and you still can talk. Yeah. Thank you very much for the discussion. Thank you.