Empathy Driven Development

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.