Introduction to 'Empathy in Tech'
00:00:00
Speaker
Welcome to Empathy in Tech, where we explore the deeply technical side of empathy. And the critical need for empathy in technology. I'm your host, Andrea Goulet. And I'm Ray Myers. And today we're talking with Ray Myers. Oh my. I'm so excited. So we have a couple of episodes in the can. And one of the first ones was about me and kind of why I'm on this podcast and you know kind of why us, why now, why Empathy and Tech. And so I'm really excited to interview you because you and I have different backgrounds. And I think that's why you and I make such ah are going to make such a great team on this podcast.
00:00:42
Speaker
So tell us a little bit about yourself and what got you interested in kind of the intersection between empathy and
Ray Myers: Career and Empathy
00:00:49
Speaker
technology. I guess you just see a series of missed opportunities in your career. And if you're a curious person, then you insist on focusing on on those things, getting better at focusing on them. One of those things has been Legacy Code, of course, ah obligatory reference to the Legacy Code Rocks podcast, which we're the sister show now.
00:01:12
Speaker
Another was the build, you know, ah release automation. No one wants to fix the build. So if you're one of the people who was willing to fix the build, there are usually some really good wins on the table. If you're just willing to get your hands dirty, while other people won't. And empathy was another one of those. I have been increasingly dumbfounded with how poor people in organizations and ah software engineers, we're just especially stereotyped this way. But you know, we don't have the monopoly on this, how poor we all are listening to each other.
00:01:50
Speaker
and understanding what's really being talked about, what's really being asked for and why it's become a drum that I beat. If you just go through life pointing out when you don't think listening has occurred, it will become the thing you're saying every day. It's just natural. The opportunities are so rich in most environments for for that. So I guess I guess that's how I became kind of a minor in empathy without realizing it. Yeah. And walk us through a little bit of your career journey. So you are a software developer, right? Yeah. So I started my career in 2007 at Carfax. And as a backend Java developer, we were doing extreme programming at the time was one of the the biggest rigorous implementations.
00:02:34
Speaker
of extreme programming. So that's in the in the Agile community. And so I was I was radicalized by Agile done right as we as we saw it. Right. A lot of people ah I guess different ideas, what that means. But I saw. Really great benefits from, you know, focusing on ways of working right ah there. And from there, I did
Current Role and Interests in Tech
00:02:58
Speaker
a startup for a while. I became chief engineer of an education tech startup called Get Set in Chicago, and they do a student community for increasing retention. After that, I um went back into the enterprise for a while, went into finance, went into healthcare. In these roles, i was the bigger change in the industry is actually for me, was I was going increasingly into DevOps roles, ah platform engineering,
00:03:29
Speaker
ah site reliability engineering. And that's the sort of thing I do currently. im ah Right now, I'm the tech lead of Chaos Engineering for Indeed dot.com. Chaos Engineering, I love that. so And I think that's something where you and I kind of connected, was through this Legacy Code Rocks community. So people haven't listened to the previous
Legacy Code Rocks Community
00:03:50
Speaker
episode. My business partner and I, back in 2015, there was a conference. We noticed that there were a lot of people who loved fixing complex right kind of chaotic systems. And so Legacy Code Rocks was started as just this grassroots community. there's now We had a podcast, which is part of what inspired this podcast. And so I've met so many amazing people through that community. I think, Ray, like you embody a lot of kind of the characteristics
00:04:19
Speaker
of exactly what I've seen is super compassionate people who really, really care and have seen these like, Oh, like I see how this human centered stuff works and I can spot the associations and I want to know how to do this better. How can I apply it in my context? And for you, that idea, like that identity of a mender kind of just really took hold for
Philosophical Influences on Coding
00:04:50
Speaker
you. And that was kind of... where I started seeing you in Legacy Cobra, I started interacting more on LinkedIn. You started your video channel on YouTube, Craft vs. Craft, where you talked a lot about these ideas, which is why when I was thinking about co-hosts, because I think I do well with a co-host. I loved interviewing Sky, and I think you get a lot of different perspectives.
00:05:11
Speaker
and then with your background in radio too. So I was just really excited to kind of explore this because I think the Venn diagram between what we have in common, but then also where our differences are, brings such a great and rich experience in the interviews. So one of the other things that we kind of have in common is Taoism. We can touch on this for just a little bit, but this is another thing that really influences kind of your coding philosophy as well. Yeah, well, um I have now on that channel, you mentioned Kraft vs. Kraft on YouTube, 50 episodes. There's only one thing that I say in every single episode. The last line of every episode, as Laozi said in the Dauda Jing with patience, the most tangled cord may be undone.
00:06:01
Speaker
And I don't think I realized when I said it for the first time that it was going to be what I said every time that it was going to be interwoven. And what I think now is actually a ah cogent philosophy that, you know, spans the channel untangling of a chord I see as just a really intrinsic. part of how I view reality as I'm trying to exist as ah as a software engineer. Sometimes the cord is some spaghetti code and sometimes the cord is a situation and and sometimes it's it's a project plan or or what it may be. But I guess I i have developed a a radar for
00:06:44
Speaker
a tangled situation, so something that is deviated from from what I think the untangled cord looks like. But it's more than just seeing that there's something you don't like in the world. It's a curiosity for actually what is the part I can pull on successfully here. Where is the opportunity? That's where it becomes a really useful skill, ah because anyone who's untangled knows you can. Yeah, you always can. You just have to know where to pull next.
00:07:18
Speaker
Yeah, I do a lot of, uh, fibercraft. I love like knitting and refreshing and that kind of stuff. And so, yeah, there is a lot of untangling yarn in that. And I think, uh, that's such a great metaphor too. And I think it absolutely applies with legacy code. And that was kind of this idea of mender,
AI in Software Development
00:07:38
Speaker
which are these people who just find a lot of joy in that patient untangling process and recognizing that. the majority of people will just kind of throw it away and start fresh. But a lot of people in the Legacy Code Rocks! community, it's like you see the joy and you see like, no, you pull ah effort into this thing. It still works. You don't, it actually can be kind of wasteful to dispose of some of these things. Two, that definitely applies to social systems too. Like that's kind of where my intuitive thing is. And the more that I've seen
00:08:12
Speaker
both these different worlds between like empathy and social systems and then you know legacy code and software systems, a lot of the underlying principles are the same. Yeah, now for me personally, and by the way, that that's certainly not the only thing. It is my favorite line in the Daoism, but it's not the only thing I think we can take from from it. I think there are a number of core Daoist ideas that are incredibly useful, that not only for just life in general, right, but specifically being someone who's trying to fix legacy code, like doing any kind of really thankless work Daoism teaches
00:08:49
Speaker
ah being able to to try without being invested in whether today is the day that it works. I don't stress patience with this quote because I'm a naturally patient person, right? Like it's the exact opposite. I remind myself of this all the time because I'm i'm very impatient and it's it's hard to be a legacy code enthusiast when you're impatient. Yeah. And another thing too is that you're, so you're grounded in this idea of legacy code and really looking at preserving what we have and untangling these cords, but you're also looking ahead because you're doing some really cool work with mender.ai. You're looking at AI and, um
00:09:32
Speaker
like Devin, for example, which just came out recently, and you've got a project No Pilot, which is looking at kind of like creating a dashboard. So tell us a little bit about, this is another thing that I'm really excited about, is you kind of being on that more forefront of some of the industry trends that are happening. So tell us a little bit about what you're seeing there. Yeah, I sometimes say that I'm a skeptical AI enthusiast. i'm I'm both an AI skeptic and an AI enthusiast. I don't like technology for its own sake. I mean, I guess I do on some aesthetic level, but you know when you're a tech lead, you're expected to have a little more nuanced of a relationship with technology than pro or con. Do we have the responsibility to really understand deeply what's going on?
00:10:13
Speaker
And how how does it apply to say that A.I. is good or bad as some sort of universal is like saying that bash scripts are good or bad. It doesn't even compute to say something like that. But yeah, these things are very interesting. I did have a bit of an A.I. background in college, but like a kind of falling off my radar wasn't that high. There weren't a lot of opportunities to work with it. It was it was, you know, neat. But unless you had unless you had big data, you probably weren't doing a lot of machine learning at that point. But these foundation models started coming out. OK, now this model is useful for a wide variety of things without having to train your own. And specifically when they level up to the point that GPT-4 came out ah released, that's March 2023. And that was kind of a shockwave for a lot of people.
00:11:00
Speaker
The chat GPT had been out for a little while, but when it got the upgrade to GPT for the lucidity that came out of these things, you know, ah started to get really eerie. We had to zoom in. We had to take a closer look. And in particular, the code generation capabilities. Also, we needed to reckon with this. But I felt like the professional sensibilities that I had developed, you know, over the 15 years that I'd been in the industry, weren't being represented in the conversation. People were saying, well, look, it it just generated 40 lines of code or whatever. It generated a new program. It's doing the job. And i like, haven't you been paying attention? That's not the job. But that's not that's not a limitation necessarily of the of language models. It's how we're using them. it's They're asking for you real quick. So if the code generation isn't the
Empathy in Developer Experience
00:11:53
Speaker
job, yeah what is the job?
00:11:55
Speaker
Right, right. Well, that's that's worth talking about, right? Because one thing you do is type new code, but you only do that for a very short amount of a project's lifecycle. It's called software because it can change. That is the notable fact about it is that it can be read and understood and updated. So it does something it didn't do yesterday. But doing that without breaking anything is really subtle. Like that is harder. That is harder than creating something new.
00:12:27
Speaker
Therefore, if you're if you're going to help me with the easy part and not the hard part, that's almost value neutral out the gate. It's like a distraction from what's really yeah holding us back. But also the reason it's so hard to maintain our system is because we have so much of them. Yes, because there's such a big pile of code. So you're just yeah you're just saying you're going to contribute to the pile without giving us better ways of dealing with the fact that we've got a big pile. Yeah, we can get into this in another episode, but this is why I'm so excited to just like nerd out with you about some of these things. But a lot of it comes down to entropy. And so because those core concepts are the same, then you can use
00:13:06
Speaker
Metaphors that most people who aren't software developers can wrap their head around so this would be like if you had a replicator Let's use a Star Trek reference, right and you can just like oh my gosh. I have this automatic replicator I can create anything that I want. I want this new shiny object. I want this new shiny object. I want this new shiny object. but you don't organize it in your house. You just like find a place for it. And then eventually it gets really hard to just live in that space yeah because it, Oh, where's that thing that I got? Oh, now I got to spend forever trying to find it. I have to move all this stuff around and you can't actually accomplish the goals that you want to. yeah And I think that's kind of where the AI piece is coming in is that
00:13:51
Speaker
You can use it absolutely in a great way where it's very intentional. It helps you do things quicker. But you can't have like just expect that, oh, it's just going to output all of this stuff. And it's so interesting, too, because this idea of like code productivity is number of lines code written. It goes back all the way in the 1950s, like the very beginning of the whole industry. And there's so many academic papers. And there's also the developer experience movement, which is kind of starting to gain traction, too. What are your thoughts there? Because I think I see a lot of convergence there between
00:14:25
Speaker
kind of a recognition of exactly what you're talking about. Like, yeah, okay. we Writing code is one thing, but there's a whole lot other of other things that have come into it. What is it from kind of your early XP days where you were saying that you felt like you had a really good developer experience? What are some things that you've seen kind of over the course of time that have contributed to your being productive and being able to do well and kind of the things that have hindered you too? Well, I think I associate a really healthy developer workflow with being able to move with confidence. That is, if we want to change things, that's something that I really think about. If we are moving faster in a a way that makes me less confident than the moves, I don't see that as actual speed, right? I see that as an illusion of some kind. You can describe it as a philosophy that's almost like the opposite of move fast and break things.
00:15:18
Speaker
Right. My understanding of the situation is move fast and break things simply takes you to a place where everyone's moving slowly amidst a bunch of broken stuff. It's like it's like a 40 car pile up in the highway. I mean, we move fast and broke stuff, but ah we're not moving fast now, are we? Being able to move with confidence and safety is to me the healthy developer experience and the disciplines that allow us to do that while they do sometimes feel slow. The consistency of going well does actually mean ah we're going quite fast. We're able to execute what people are asking us for very confidently. We're able to give them assurances that we're going to solve their problems. We're not in this chaotic situation or all this slapdash stuff. I think about safe practices and sustainable ones. Yeah. And I think empathy is a big part of that. Like I think when I read all of the, you know,
00:16:17
Speaker
little a agile, like, you know, Kent Beck's work on extreme programming, you know, Alistair Coburn's work on crystal, like, there's just a lot of kind of like pre agile work that is really awesome. um And even the like, scrum, you know, some of the more, you know, formalized methodologies there is an underlying assumption in all of them that you are able to work together and understand each other and that you care about each other as a team. And it's almost like so foundational that it's kind of just unsaid, right?
Empathy-Driven Problem Solving
00:16:50
Speaker
And to me, that's been really interesting is that like looking between the lines, because even what you were describing, like being able to you know talk to people who are different stakeholders and help them understand what you're working on, like that definitely requires empathy.
00:17:06
Speaker
Tell me a little bit about your personal like identity and how, cause we had had a little bit of a conversation about this before, but how during the course of your life, your career, have you personally related to the concept of empathy? Well, I think initially I did have kind of a radar. It wasn't, till later that I realized how useful that radar was. I would describe it in terms of pain. Some people have even described this as like pain point driven development or pain driven development or something. This was kind of an intuition that I would have. If people are hurting, you fix it. Someone may have some story about why fixing the pain isn't the right thing right now.
00:18:00
Speaker
but I don't find those are particularly well-defended usually. I don't let pain stick around for the sake of momentum. I mean, you know, it's not that I like abandoned my day-to-day work, but I've always felt like I should have a ah somewhat of a latitude to address pain where I saw it. That seems just obvious to me. I don't think that we would be professional knowledge workers if we didn't have that purview to identify this, this just shouldn't be this way. Actually, in the first year of my career, I had a huge win that maybe reinforced this value. That was at Carfax, and we were talking to, I think, one of the business analysts that kind of gave gave our team work. My team was ah maintaining the rules engine that determined what goes on at Carfax.
00:18:47
Speaker
and They were talking to us about this, oh, well we found that in this scenario of a vehicle history, and the the quirks so of what goes into all these data sources in order to produce a trustworthy report, very, very difficult problems there. There would always be these these weird edge cases. They're like, wow, how do you find that? like How are you finding these vents? vehicle identification number. right like how How are you finding these these bins with this history on them? And they said, there's no there's no way. we're just We just manually run hundreds and hundreds of reports, and then we find them. Immediately, my radar goes off. like This will not stand.
00:19:29
Speaker
These are the people I'm supposed to be looking out for. These are these are, you know, my internal customers. Right. Now, they weren't asking me to do anything about it. The idea that we would actually be the ones to do anything about that wasn't on the table for it. Right. Like they were asking us for stuff, but they were asking for changes to the product. They weren't asking us for things to help them. That just wasn't of their habit, right? But they shouldn't have to be doing this. This is the work of a machine. This is not the work of a person. So yeah, I went off and and in hindsight, what I did was invented the world's first vehicle history search engine.
00:20:06
Speaker
But it wasn't that that was that technically difficult of a thing. I was probably, you know, punching above my weight for being my first year in the industry. But it was simply that no one had plugged those concepts together before. Right. You would never in a product. You would only do that because internally we had particular needs that allowed them to in a whole you know array of new scenarios be able to quickly find things that exhibited the behavior they were interested in. Right. And this like changed the way they did business. But from a process standpoint, no one was ever supposed to be approaching a problem that way. No, one no one was supposed to be doing that. But it didn't even occur to me that you would not because they were hurting.
Trust and Innovation in Teams
00:20:48
Speaker
Yeah. Yeah. And I think that is there. That's an example of how so many people on the legacy code rocks community just operate um where and that is compassion.
00:21:01
Speaker
Right. Like I see you hurting. I want to fix it. And empathy is then really understanding the perspective of someone. you know, to figure out how, what's their perspective on how they can work. And then being able to collaborate together to find something. And I think that's, that's where we eventually want to go where we can empower people and we have enough trust and we have enough autonomy. And there's a lot of stuff systems wise that needs to be in there in order for these things to operate successfully. But I think that's just such a great example of
00:21:36
Speaker
you know It's about problem solving. It's about complex problem solving. And I think you know coming from a non-traditional computer science background, when I first, you know kind of I didn't know really what a machine could do and like what the level of effort would be in order to ask for things. So I didn't even know what I could ask for. And I think that's the really amazing thing when we can know what's gonna help each other like There are things that I do that's like, oh, that'll take me five minutes. But for other people, it's like, oh, my God, that would take me three days. And so when we can know that about each other, we can know where those pain points are and then we can collaborate um to help each other. That's where we get lots of innovation. That's where we go. That's our creativity.
00:22:20
Speaker
And I think it's really cool that you've experienced that, especially because you experienced it so early in your career. And a lot of people haven't had that experience of working on a team that it feels magical because then you build this trust and it's like, we can take on the world. We could solve so many things together. I might be putting words in your mouth if that's how you felt, but that's how I felt on teams. At the best times, you know, yeah that there we had moments like that. for sure and an enabler of being able to solve problems in unorthodox ways. And I know you talk about psychological safety a lot.
Podcast's Motivation and Mission
00:22:54
Speaker
i feeling that you can try something without any fear. Like he was probably talked to people who were in a situation I would feel like if I were doing something that was outside of my team's normal responsibility, that I'd be somehow punished for it. I've learned there's a certain finesse to being able to do things you're you're not technically supposed to be doing, but you're pretty sure people are going to be happy you did it. You know, like I've i've learned to get more subtle, but I started out in a very high psychological safety environment from that point of view. right they They were explicitly blocking off time for kind of learn and play and, you know, whatever, ah become a better developer every Friday afternoon, you know, like, so so they were ah actively encouraging, not just the absence of discouraging experimentation, but actively encouraging. That's awesome. And I think, you know, two more questions. What makes you excited about doing this podcast project together?
00:23:49
Speaker
Well, I mean, to ride your coattails, obviously to, you know, no, no, no, no, no, no, no, no. So as we've talked about it, dovetails with a lot of the messaging that I like to put out there and. In terms of why now, I think we've both independently identified there are important conversations happening. And that alone does not justify entering it. Right. But there are aspects of that that we feel are very neglected. So just like.
00:24:25
Speaker
I initially was very passionate about like, okay, well, the GBT4 coding conversation is not accounting for the fact that code is not only written, but it is read and updated. It so so it is ignoring just the most basic fundamental things about what we do for a living. And it doesn't need to ignore that. That was a user error. Also, then, yeah, humanity is largely being left out of the conversation. And and what are we even what are we even trying to achieve? So I think that is something that you're um you're really well positioned to help tease out of the woodwork as we have a chance to maybe talk to a bunch of other people that have that have felt this way.
00:25:08
Speaker
It is a cord that together we are going to very patiently untangle. That's right. Yeah. So in one last question, which we're going to ask all of our guests, um what is one thing that you think right now should happen at the intersection of empathy and tech? So my previous answer was that we just think about what our actual goals are, not see technology as a goal in and of itself, even though I do love technology. That's certainly still a big one. I'll add something that was talking with someone about earlier today.
00:25:52
Speaker
They were asking me what I thought of of Microsoft Copilot. I said, well, i've I've only used the one for code, but, you know, this is my my spiel on it. And then sort of absent mindedly after that, I say, you know, this is like the superpower that everyone is insisting on. But you know what is actually a superpower is just having an actual copilot next to you. It's just actually talking to someone else. That is, you know, maybe in an adjacent role or or the same role and know some things that you don't. There's kind of an irony, even though I i do think these tools are really cool, that there's an irony that we are so fascinated with that while we ignore the wins that are right in front of our face. If we could identify the most people who have coworkers at all.
00:26:40
Speaker
are ignoring just very clear wins you could have in in terms of. um Let's have more of us know what each other now. Yeah, that's awesome. And I love that. And I can't wait to kick out more. All right, well, we're going to wrap it here. We're trying to keep our conversations to around 30 minutes, a whole bunch more questions. And we're going to, I think, make each one of those its own episode. But thank you so much, Ray, for sharing. And I'm really excited about collaborating with you on this. And thank you for listening.
00:27:10
Speaker
You know, what is this? Empathy in tech is in the process of becoming a nonprofit. So in addition to the podcast, there's also an online community. And our mission is to accelerate the responsible adoption of empathy in the tech industry. And doing things like closing the empathy skills gap and treating empathy like a technical skill and teaching that technical empathy through accessible, affordable, actionable training. building a community, breaking down those harmful stereotypes and tropes, and really promoting technical empathy for ethics, equity, social justice. So if you found this conversation interesting, then head over to empathyintech.com to keep the conversation going and join our community of compassionate technologists, right?
00:27:58
Speaker
I forgot to ask, how can people get in touch with you? Yeah, I'm on LinkedIn. And if you look up either my YouTube channel, Craft Vs. Craft, or my website, mender.ai, you will easily be able to, in the metadata for any of these things, find my LinkedIn. And that's probably the best way to get home. Awesome. All right. Excellent. Well, I'm looking forward to many more conversations with you, Ray. Hopefully you who are listening are looking forward to many more conversations and joining the conversation over at empathyintech.com as well. Thanks so much for listening and we'll see you in the next episode.