Chris White: 0:00

Welcome to the Zeal, Interestings Podcast. I'm your host, Chris White. Today I have a very special guest? April Wensel. She's the founder of Compassionate Coding. Thank you so much for joining me, April.

April Wensel: 0:08

Thanks for having me. I'm excited to be here.

Chris White: 0:10

Yes. I'm excited to have you and I want it to kind of get your background, kind of find out what's up with Compassionate Coding and get the story of how you started that. Can you give everyone an introduction to like where you've been in your career and what led you to start Compassionate Coding?

April Wensel: 0:24

For sure. So I have been in tech for about 10 years now, a little over 10 years, kind of the traditional path. I studied computer science in high school and then college and then I went to work in tech in silicon valley and so I was there at various startups, quite a few startups and some larger companies as well for about 10 years as a full stack software engineer and you know, I always kind of took on leadership roles even informally to begin with. And then I eventually moved into formal leadership roles, but still was always coding and I just looked around and saw through all of my experiences there just a lot of problems with the industry, a lot of suffering going on among various people. So it seems like projects were often failing because of poor communication on teams, more so than technical problems. And I saw that of course the lack of diversity, me being a woman in tech and seeing like how few there were, that always bothered me and people burning out. People just didn't seem very happy around me very often. And so you know, all of these things, the common denominator there is that people, we just weren't caring enough about the human beings involved in the process. And so a combination of kind of frustration and inspiration that led me to start Compassionate Coding, to try to solve some of these problems by teaching how to care about people in the workplace in a way that makes you more productive. And that is better for the bottom line as well.

Chris White: 1:44

That's really awesome. I have so many questions. Your company, it's a, you know, it's a service business. You partner with companies and help them try to solve these problems. What does that primarily look like? Are you helping them? Are you helping leadership come up with strategies or are you doing trainings?

April Wensel: 2:00

Yeah, so it's mostly trainings. So what usually what an engagement looks like is the company will reach out to me when they either have some problems going on or they just want to offer it as sort of a perk for their employees because a lot of what I talk about helps with avoiding burnout and whatnot, so sometimes it's just to help equip employees with some strategies for dealing with that. So I'll talk with engineering leadership and find out what the most challenging issues are on the team and sometimes these are technical issues like in terms of like officially technical. I use air quotes when I say that because I think the differentiation between technical and nontechnical is kind of arbitrary, but sometimes it's literally code issues where it's like people are writing code that's literally not compassionate because they're not thinking about the people who are going to maintain this code in the future. And so sometimes I go and I'm talking about, you know, clean code and refactoring and very code centric topics. Sometimes it's sort of in between I'm talking about code review practices and how to give feedback in ways that are productive and helpful and not condescending or snarky. Yeah, and then, and then it goes up to you know, maybe mentoring and how to do that well, how to onboard people and things like that. So it's really quite a range. But, the common thread there is just this combining compassion which is just caring about people looking to eliminate pain points with coding software development.

Chris White: 3:22

It turns out that like software is made by people and if people are being ineffective at working with one another or they're like burning out or anything like that, then that process breaks down. I also liked your point about refactoring and code quality. Um, it seems like if you're unkind to yourself in the future or your coworkers or whoever is there in the future that can be a big disadvantage. I definitely look at some things some days and I'm like, wow, what was that one person is thinking when they wrote this code and of course, you know, more likely than not, you'll look at the version control history and it was you. So it's like, yeah, I guess that, that uh, that Bozo was still here.

April Wensel: 4:01

Totally. Yeah. It's funny because you know, there's the joke about like how one of the hardest things in software development is naming variables. And I think the reason for that is actually not what people normally think, but naming variables really requires a lot of empathy because you know, the machine doesn't care what you call the variable. You're naming variables for human beings who are going to read the code, including yourself in the future like you mentioned. And so that's a very specific example of how being able to empathize with what somebody is somebody is going to need to know in the future to understand your code is really what you need to think about when you're naming variables.

Chris White: 4:31

That's awesome. That's awesome. What have you found to be the most effective change? Like if, if someone were to like create a, you know, buzzfeed style, listicle of the top five most effective things to change, what are like the main things that people are doing wrong that, that they can change really quickly or that had been turnarounds that you've seen?

April Wensel: 4:51

Yeah. So it really does vary across teams a lot. But it's true that there are some patterns that I see over and over again. And I think one of the biggest things teams do is not communicate about what's really bothering them. So a lot of times people come in and think because, you know, when they hear about my company, they're going to, they think that it's about being fake nice. Because Compassionate Coding. Like I think, um, you know, I was doing a fireside chat one time and someone said, Oh, you're the, you're the lady that comes in and tells people to be nice to each other. And I'm like, no, actually quite the opposite. Like in the companies where I worked, I think sometimes I was seen as a troublemaker, sort of because I would call out issues as I saw them. And so that's kind of what I do when I come into the software teams is I call out issues based on observations and I don't have to worry about company politics so I can just call it like it is. And so I think that that's what we need to do more of is called it like it is, but you can do it in a compassionate way. So I guess one of the biggest things I see on teams is just, there's a lot of sort of quiet suffering going on. There's frustrations that are unexpressed. It's like, you know, and it comes out and passive aggressive kind of comments. Like, you know, people are always joking about how they hate meetings and oh that's such a stupid meeting and it's like, you know, meetings can actually be really great and effective tools to get work done better. They should be, you should work to optimize your meetings, not to just kind of make fun of them and whatever. I was on one team and somebody who had been promoted to a management position but he was mostly mostly because he was just a, you know, a good engineer and he wasn't really equipped with training and he was always complaining about having to do is one on one. And I was just thinking like I'm so glad that I'm not reporting to this person because you don't want to be reporting to somebody who doesn't want to talk to you and doesn't see the value in mentoring you. So really what that guy needed to do is talk about his problems rather than making passive aggressive jokes about them. So that's one of the big things is just you know, airing, airing of grievances sorta, but in a productive way. It kind of like, um, you know, like agile retrospectives, right? I love those because when they're done well there this really great opportunity for people to share what's really on their minds and what's really bugging them and what they want to improve. And I love the emphasis on, you know, looking to improve to the future, not on blaming anyone. And so I think, you know, stating, you know, being honest and how you're feeling. And then two, I think if you're not doing agile retrospectives, start doing them because they're great for any team and for individuals. I try to do one for myself once a week on what I need to improve and what I'm looking to change. So I think that any sort of like regular reflection is great. However you formalize it,

Chris White: 7:20

That's fantastic. I've noticed that my personal happiness in my own job has been really tied very closely to the like the open, how open the environment is to, to feedback and you know, the, like you said, the airing of grievances and the, it seems like if, if everybody is holding in all their frustrations than A) you're not gonna, you're not gonna improve your organization because all the problems that are hidden to the leadership which is not productive and also, you know, there's just a certain amount of- I feel like in organizations where I haven't been able to or haven't felt as free to talk about problems inside the organization that leads me to not trust the leadership of the organization. Like I usually I don't feel like the organization, like if I, if I air my grievances, that's just going to make the leadership hate me and you know, and not like enjoy working with me or feel like I'm ungrateful. And so yeah, I could definitely see that being a huge area for people.

April Wensel: 8:16

Yeah. Another great technique is there like little changes in vocabulary and languages that I tried in language that I tried to instill in teams, so one is to avoid this idea of like, right/ wrong thinking, which is very popular among software developers. You're doing it wrong, right?

Chris White: 8:31

Absolutely. We're very binary people.

April Wensel: 8:33

Exactly and I think that that's harmful in terms of effective communication because really a lot of times it's really how you're looking at the problem versus how someone else is looking at the problem. Also what facts you have and what experiences you have and even what priorities you have versus what the other person's priorities are. Because sometimes the feedback you're giving to somebody is not going to be as relevant to them because they don't have the same goals. So you sometimes see this when a manager will give feedback on someone's communication style and try to get them to communicate in the same way that maybe the manager does and that's maybe not aligned with that person's goals. And so, you know, I think this idea of this is the right way and this is the wrong way, just leads to arguments. I mean, even things like no, tabs versus spaces and all this ridiculousness now become jokes in our industry because people can't accept that, oh, I respect that you prefer this, I prefer this and we can both live happy lives and not argue all the time about this. Um, it's kinda silly. And so this is why I felt like I needed to start my company because it's not just like, oh, once in a while there are some disagreements in software. It's like baked into the culture that people have rants and just, you know, vicious kind of arguments that where you would just attack somebody's identity based on what programming language they choose to use, you know, like, oh, use PHP, oh you must be a terrible programmer. Like these kinds of comments just get thrown around, you know?

Chris White: 9:52

Right, right, right. I feel like I've definitely been guilty, especially early in my career when, you know, I was finding things that I liked, things that I preferred. I was certainly guilty early in my career of being like, well, anybody who doesn't use rails is wasting their time and building web applications too slow. And you know, I think that, that, that sort of attitude it does to me, it's whenever I see it today, I just think that's, that's immaturity. And I feel like I'm more, the more I see people doing things different ways, the more I see that the, you know, every, everything has pros and cons. A really good example is my current pair and I, we work at the same consulting company, but we come from fairly different backgrounds. Like I've mostly worked on very small teams on very early stage startups. Whereas my pair has had a much wider variety of experiences in different sizes of organizations. And so whenever I look at a problem, I'm, I'm usually looking at the point of view is like what is the minimal approach we can take here that will make our integration tests pass. Whereas I think that my pair frequently thinks like, well if we do it this way, then we might run into this problem down the road and if we look at it this way or if we only do this, then we're kind of ignoring potential issues here. And I feel like the quality of the solution that we're building right now is really benefited by having both of those angles.

April Wensel: 11:05

That's a good point. That's the thing is there's, when there's healthy kind of tension like that, meaning that there's some different opinions and you're able to talk about it without coming to hate each other or anything like that. I think that's great. I was reading a code review on an opensource project not too long ago and it was a similar thing where someone was giving feedback saying, well what about when this changes in the future and you know, something, something like we need to worry about this. And the other person was like, well that's a trivial concern. And that was their response. And it's like, so like those kind of things that happen. And it's like, yeah. So you know, I think sometimes you can tell that's clearly, it sounds like a logical thing. Like oh, that's a trivial concern. But that is clearly when using the word trivial, there's some emotion baked into their most likely. And so that's another thing, another tip there is just to, when you're about to say something or especially write, something, take a breath if you're emotional and maybe step back before responding because you can do some damage that's hard to repair on teams, especially in Code Review. That's one of the most toxic kind of areas that sometimes teams have to deal with. I've been on teams where people have almost quit over like a bad code review because it was just so vicious, you know?

Chris White: 12:09

Yeah. The GITHUB PR interfaces, texts only, right? I mean you can throw emojis in there which helps in that case where it's like that's a trivial concern. Maybe that engineer wasn't intending to tell the other engineer that like, you're thinking about silly things, then you're worrying about the wrong things and you're, you might be a bad engineer because of that, like that. That's one reading of, that's a trivial concern. Right? And once you, once you commit to like terse language that has loaded words in it, you give up the ability to like actually convey your real intention of what that maybe the engineer was just thinking like, hey, that might be a problem in the future, but I'm not worried about that right now. And the project as a whole isn't worried about that right now. Like maybe that's what they were thinking, but they wrote those words and so they kind of left it open to like, you know, for, for the other engineer to be trashed by it.

April Wensel: 12:57

Yeah, I think that's exactly what happened.. So, you know, those are, those are some things that teams can look out for for sure.

Chris White: 13:02

Yeah. Yeah. It seems like there's, there's interpersonal communication issues at companies. What are some of the biggest like cultural or diversity company makeup issues that you see in software companies that you work with.

April Wensel: 13:16

You know, I think one of the biggest things is just this sort of assumption that anybody who's a software engineer has to exhibit certain stereotypical traits that, uh, in order to be a good engineer.

Chris White: 13:29

The pattern matching when you're hiring?

April Wensel: 13:31

Yes, Exactly. Exactly, and you know, it's not always just appearance. I mean, of course that's an obvious one, right? Like, you know, Oh, if you're a white male probably you know, you, you're kind of fitting my view of what an engineer looks like based on, you know, what I've encountered in my career in pop culture, right? So say appearance things, but there's even subtler things like in terms of this obsession with doing side projects in your free time and doing coding all the time in your free time. I can see a sewing machine in the back there. I'm curious if that's, if that's yours.

Chris White: 13:59

Uh, I cannot actually claim those things. And so they are my wife's activities, but I completely agree with what you're saying earlier in my career, my aptitude to doing side projects was so much more than it is today and today I'm actually dealing with the opposite problem where it's like there's all these outside of work things that are still ongoing and their legacy things that I'm trying to wind down and like reduce the amount of time outside of work that I'm spending coding. And so it's an interesting tension there, but I've definitely changed my own personal interest in that.

April Wensel: 14:29

Yeah. And some people might not realize why that's a diversity issue, but it's just that, you know, different people have different passions and interests in terms of how they approach life. And so for me, I always like, I love coding. I mean, like I mentioned, I started in high school. I really enjoyed it. It was kind of fun. It was like solving puzzles. I always enjoyed it for the pleasure of actually coding. But now that I've gotten older and I just see how much of the world there is to experience, I don't want 100 percent of my time to be in front of a computer, you know, I'm into running and cooking and reading actual physical books and all these sorts of things that bring me joy and actually, you know, not that they need to, but they actually make me a better developer as well because for one they helped me clear my head but two, you know, some of the collaborative volunteer projects I do give me experience, you know, dealing with different groups of people and you know, navigating social situations that may also come up in the workplace. So I think this idea that you have to be coding all the time in order to be a good engineer is a harmful stereotype. And you know, a lot of the old blogs from people like Jeff Atwood and Joel Spolsky kind of made it clear that, you know, that means to be like, you know, the 10x rockstar programmer, you have to be coding all the time. Like Jeff Atwood has the quote about the machine picked me or something like that and it's like those people for them that's great. Like some engineers, that's the case. They feel like this kinship, but for other people, and I've noticed this more among women, I mean I don't like to generalize, but I will say in my experience I've seen this more among women where they're more concerned about the results, like what we're doing with the code, what we're trying to build, what we're trying to accomplish, and that's what's motivating and I think that that's perfectly fine, right? Like, we should welcome all of these perspectives and all of these motivations.

Chris White: 16:14

Yeah. Yeah, that's really true. I found that I've, I've had the privilege of a few times being connected to hiring processes with engineers throughout my career and when I'm looking through, you know, you have the resume, the cover letter, so you have the links to GitHub, et cetera. You know, I've definitely found myself falling into those same thought patterns. It's like, oh well this person's GitHub project has really great test coverage and that must mean that they're a good engineer and that means that the people that don't have that same thing don't, aren't as good of an engineer. And so I think the, I think the, you know, no matter who you are, there's definitely that, that built in ability to put people into buckets like that.

April Wensel: 16:52

Yeah, I think that's definitely true. That's funny because I don't think for any of my projects on GitHub, I have test coverage, but when I actually work at a company I'm like obsessive about test coverage. Like, like I, I was pleased that we kept like 99 percent coverage or something like that. And you know, only thing I know coverage percentages only one indicator, but I was pretty obsessive about it and I actually really enjoy tdd. I teach workshops on Tdd, but what's funny is if I'm just building a little fun thing, it's not necessarily gonna test it. Most of the best code I've written is not public code that I can share. And so, you know, and I think that that's true for a lot of people who care about their work and like that's the thing is what I'm focused on like a job. I put so much, I put 100 percent into that. So that's the other thing about side projects is sometimes you know, they reward people who kind of do maybe a half hearted kind of thing on multiple things rather than focusing all in on one. And so you know, you're going to. I think that's why you need a balance too of people with different sort of backgrounds.

Chris White: 17:48

I had another related to culture and makeup of teams. What are, what are some of the important changes that teams of any size can make when they're trying to build a more diverse team? I was listening to a talk, I'll have to link in the show notes because I don't remember what it was, but the focus of the talk was like, don't get into a scenario where you have a non diverse team and you're trying to grow into a diverse team. If you can start with a diverse team, you're way better off, but you know many, many companies and teams have the problem of the people inside the team don't feel good about the makeup of the team. In terms of diversity and diverse backgrounds, what are some of the most important steps that teams like that can take to start, you know, correcting that issue?

April Wensel: 18:33

Well, one is really to do some kind of training in unconscious bias and I know a lot of people don't like this kind of training because the think, oh, I don't need people to tell me that I'm biased, but here's the thing that I hope everyone understands is that we're all biased and I include myself in this set and no matter how much training I go through, I will always be biased because that's just human nature is we have certain biases that are shortcuts in our brains where, you know, like we talked about pattern matching. We have these and so I think it's really important before you try to bring people from different backgrounds onto the team that the people who were already on the team are going to be welcoming and I think that some kind of training and that can be very helpful because we don't even realize all of our biases. Like I mean we make biases based on how people talk, you know, and those that can be harmful. And so I think doing that kind of training is a good first step. I think it's important to read, to kind of do an overhaul of the hiring processes because again, there's a lot of ways to accidentally rule out people in terms of looking for what you've always seen means a good engineer, you know, versus, oh this person took a different path and they have different experiences and they're going to bring a different perspective. And because there's so much work on a software team too, that's not just coding all the time. And so if you're only checking for whether somebody can write code alone under pressure, like I don't think that that's a good way to hire people. And it also introduces a lot of issues like stereotype threat, which is this idea that people from underrepresented groups when they're forced to perform under pressure, they have an additional fear, anxiety of confirming negative stereotypes about their group. So they're going to perform even worse. So I like, I feel this when I'm doing like a whiteboard interview or something, which thankfully is, is mostly in my past now. But actually now...

Chris White: 20:14

How good are you solving computer science issues without Google?

April Wensel: 20:20

Yeah exactly, you know, now I'm lucky to be in a spot where, you know, if I were to apply somewhere, I don't know, in the future if I decided to change paths, I would just walk away. Like, I mean the thing is like now I'm just like okay, that's your hiring practice, clearly have issues here, so I'm out. So, but, and I encourage other people to do that when they can because there's no reason to put up with a kind of demeaning hiring processes. But yeah. So, so, you know, at a whiteboard interview that can be really stressful sort of thing. Anyway, like you said, it's not like the day to day jobs. So, um, and I think it's very different even from like a testing scenario because I was always very. I love tests. Like I love studying for tests. I love taking tests. I'm total nerd in that way and I always did very well on tests and so. But whiteboard interviews, they're very different in the fact, like for multiple reasons. One, there's not clear material that you can prepare so there's no way to really like perfectly prepare for them. So there's a lot of unknown. And so to go into that sort of stressful environment, especially in front of people who don't look like you, who are assuming that you don't know what you're talking about, is just one of the worst experiences that you can go through because they're expecting a lot of times whether they know it or not, they may be expecting you to fail. And so their expressions may indicate that and that's gonna make you perform worse too. There are studies that show that when people have sort of, they're like crossing their arms, leaning back, looking at you disapprovingly you'll actually perform worse. So anything that puts people under pressure like that, I think it's the best to be avoided. Would I like to do is kind of offer people a range of things that they can do. Like maybe pair programming is one of them because that's more collaborative and I think that that gives great insight into what it's going to be like to work together from both sides. Showing past projects if they happen to have them, so that's like an option. Potentially doing some kind of take home exercise. Again, if they prefer. Like if you provide these options then you kind of have can again have more diversity in terms of your candidate pool because these are different styles that will suit different people and you can have a standardized rubrics so that it's fair to judge people's skills across those different types of projects. But some kind of range like that. And then I also really the best tool I think in hiring, especially for diversity, is talking about past projects and asking really detailed technical questions about them too, you know, because there's this fear, oh, someone's making it up, which I'm sure they're not. But you know, that's like another thing is to like give people an opportunity to talk about what they're proud of and to talk about what, give people the opportunity to show their strengths. And then final tip on diverse team thing, don't just hire one person that doesn't look like everyone else on the team because they're going to feel isolated. So at least two. But of course, you know, the more, the better.

Chris White: 22:46

Definitely, definitely the main thing that I try to look for when I'm trying to find new colleagues is the ability to communicate and the ability to solve problems. And I feel like whiteboard interviews are really, really. I mean, you might be able to elicit some of that, but I think that like they're so unlike the work that we do that exercise is like, like live pairing or asking about what projects and kind of teasing out the decisions that someone made when they were working on those things is super helpful. One common thing they hear, especially when companies or groups are challenged on their, on their hiring practices, is that the diverse hiring pool is not present. I'm not sure that I necessarily agree or believe in that, that counter argument, but as far as a team that's looking to improve can do. How do you attract more diverse talent or talent that just doesn't have the same background as your existing team?

April Wensel: 23:38

Yeah, and I think that one thing to do and I think a lot of teams use as a cop out to be honest, let's call it like it is.

Chris White: 23:44

It sounds like a cop out.

April Wensel: 23:46

Because like I will say that like I was, have built out an engineering team. Like I was the first one and they built them out and we were like 50 percent women of color, like diverse ages. And it just happened because you know what it was when you take the steps to make it happen, you can make it happen. I mean, what we solve all these complex technical challenges and we can't find candidates. I mean it's just, it's kind of silly, but anyway, but that said, for people who are still using that excuse, here's what you can do, one is to seek out meetups for women, people of color or other underrepresented groups and then people there to like recruit and just, but also just to like talk with people. Um, I think, you know, sponsoring events like that too you, it can be helpful in terms of, you know, you don't want to do it just for the show. But I mean in terms of actually attracting clients, candidates, um, most important though is to, like I mentioned earlier, like make your culture friendly and inviting to those people. So like what's on your hiring website? Like if your website, you know, and it's hard because if you're just getting started and trying to diversify and so your team pictures are going to be all white guys like that's not going to be very inviting to me or to, you know, other people from underrepresented groups because like oh I'm going to be the only one and I've been the only one many times and I can do it, but it's not the most pleasant experience because it's like you're always the one that's like, people are like, oh look the girls here, oh look, you know, just horrible things that you have to deal with. So I think that, you know, trying to make your website more welcoming too. And that might mean maybe you don't just like talk about how everyone gets beers together because that's not necessarily something everyone wants to do. You know, maybe you have diverse perks that you share as well. There's things like that. So I think getting different perspectives on what you're putting out there is also helpful. And also your actual job ads. Like what language are you using? Are you using really aggressive language? Like I was reading some job ad that was talking about sweat and blood and tears and everything. I'm just like, that's not appealing to me. Yup. No, no, that's not appealing to me. I think if you talk about like collaborative environment, things like that and there are tools out there that will do a read on masculine and feminine coded words and your job as they're not perfect, but they're a first stab at that and then the other day it's actually pay people who do this kind of work to look at your job ads and whatnot because that's the other thing too is a lot of times people ask me to do read that their stuff for free and I'm like and other underrepresented people as well and it's like that's not really... This is important work and so it needs to be compensated, so if you're going to ask people to do that, you've got to compensate them too.

Chris White: 26:04

That's a great tip. That's a great editing for different reason. That's awesome. We're coming up on our time, but I wanted to ask before we go, is there anything that you'd like to draw our listeners' attention to or anything that you'd like to promote via the podcast?

April Wensel: 26:19

Sure, yeah. So if people want to stay in touch and you know hear more interesting opinions like this. I've got a newsletter at compassionatecoding.com. I haven't sent out so many recently because I've been giving people a break and kind of making some plans, but I'm going to start ramping up pretty soon on sending those out. So compassionatecoding.com is the best way to stay in touch and my twitter is@aprilwensel, so that's another way. I tweet quite a bit.

Chris White: 26:41

Very cool. We'll definitely put those links in the show notes. Thank you very much April for joining me today.

April Wensel: 26:46

Thanks for having me. This is super fun.

Chris White: 26:47

Yeah, definitely and thanks everyone for listening. If you'd like to, you can follow us on twitter@codingzeal and we'll see you next time. Thank you.