01:13 - Andrea’s Superpower: Distilling Complexity

• Approaching Copywriting in a Programmatic Way
• Word-land vs Abstract-land

09:00 - “Technical” vs “Non-Technical”

• This or That Thinking

16:20 - Empathy is Critical

• Communication Artifacts
• Audience/User Impact
• Programmer Aptitude Test (PAT)

33:00 - Reforming Hiring Practices and Systems

• Core Values
• Exercism.io
• Retrospectives

39:28 - Performance Reviews

• Continuous Feedback
• Brave New Work by Aaron Dignan
• Team of Teams: New Rules of Engagement for a Complex World
• Continuous Improvement & Marginal Gains

“Start where you are. Use what you have. Do what you can.” ~ Arthur Ashe

Empathy In Tech
Corgibytes

Reflections:

Mando: Empathy is being able to view and identify other perspectives.

Jess: Help happens when you have empathy for individuals who aren’t the great majority of people using the software.

Casey: The best way to develop empathy for someone else is to get their feedback. Do it during an interview!

Andrea: Diving deeper than code is valuable!

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

JESSICA: Good morning and welcome to Greater Than Code, Episode 237. I'm Jessica Kerr and I'm happy to be here today with my friend, Mando Escamilla!

MANDO: Hey, Jess. Thanks. I am happy to be here with my friend, Casey Watts.

CASEY: Hi, I'm Casey and we're all here with Andrea Goulet.

Andrea is a sought-after keynote speaker for conferences around the world, empowering audiences to deepen their technical skills for understanding and communicating with others.

She is best known for her work defining Empathy-Driven Development, a framework that helps software engineers anchor their decisions and deliverables on the perspectives of the people who will be impacted by what they create.

Andrea is a co-founder of Corgibytes, a software consultancy that helps organizations pay down technical debt and modernize legacy systems. You can recognize her by the JavaScript tattoo on her wrist.

Welcome, Andrea.

ANDREA: Hi, welcome! Nice to be here.

CASEY: We always like to start with a question, which I think you’re prepared for, that is what is your superpower, Andrea, and how did you acquire it?

ANDREA: Yeah! First of all, I just love that y'all ask this. I think it's just such a nice way to get to know different people.

I was thinking about this because you sent it a little bit ago and I was thinking maybe empathy, given the work I do. But I don't actually think that's it. I feel like I'm constantly trying to learn more about empathy, but I do think that what my superpower is, is distilling complexity.

So I went back and looked at what the thread is of all the recommendations I've got on LinkedIn and things like that. It's not something that I would necessarily say that I noticed, but it's something that other people have noticed about me. The idea of taking a really abstract and big, gnarly, complex topic, and being able to distill it down to its essence and then communicate either what the importance is, or what the impact is to other people. I think that's why I've gravitated towards big, gnarly things like legacy code. [chuckles] Because what motivates me is impact and how do we have the work that we do make as big of an impact as possible?

So the way I got into software was really a twisty and windy road. I started out as a copywriter and I think that's where the distilling complexity comes down because I would sit with clients and learn all about their businesses. And then I would write typically, a website, or some kind of marketing material and they would say, “You said what was in my head and I couldn't say it.”

JESSICA: Wow.

ANDREA: And when I got into software, I had a friend of mine from high school, Scott, who's my co-founder at Corgibytes, he came up to me because I had been writing about my writing and he said, “You're not a writer, you're actually a programmer because the way that your brain works, you’re thinking in terms of inputs and manipulating data and outputs, and that's exactly what a programmer does.”

So then, he wanted to fix legacy code for a living. I didn't even know what that was at that point, thought it was a good thing and I found that my ability to both walk in and understand not just the syntax of what's going on, but the business challenges and how everything links together. With that, you can create a sense of cohesion on a team and getting different people to work together and different people to see each other's points of view, because when you're able to distill a perspective over here and say, “Okay, well, this is what this person's trying to say,” and still, this over here. “Okay, I think this is what this person's trying to say.”

I feel like a lot of times I am kind of like a translator, but it's taken me a long time. I've been in software 12 years now and I still have massive imposter syndrome like, I don't belong because I'm not the fastest person on the keyboard. I really struggle with working memory. My visualization is really a struggle, but I do really great in an ensemble. When I started ensemble programming—sometimes it's referred to as mob programming—I was like, “I can do this. Oh my gosh, this makes sense and I belong.”

I think just over the years, little things like hearing the joke – I was at a conference, Jess, I think this may have been ETE when you and I connected, but I heard a joke and it was, I think Phil Carlton had first said it and it was like, “There's only two hard problems in computer science, cache invalidation and naming things,” and then somebody else said, “Off-by-1 errors.” I remember I was like, “Y'all think naming things is hard?” Like, help me understand how that's hard because that’s –

JESSICA: [inaudible]? Oh my gosh, that's hard.

ANDREA: Yeah, and to me, it just comes so naturally. I think that's kind of the thing is figuring out where is your trait, where's your skillset. I remember when I first started doing open source contributions, I haven't done those in a long time, but just going in and modifying the language on help messages and turning them from passive to active voice. They got accepted, it was on some high-profile projects, and it was like, I didn't really feel like I was even doing much and I still feel like, “Is that even a big deal?” But I think that's kind of the definition of a superpower a little bit is that –

JESSICA: Yeah, it’s easy for you. [laughs]

ANDREA: You don't recognize that it's hard for other people. Yeah, and so it's neat now that it's like I'm starting to come into my own and leaning into that, and then helping other people see that the way that I approach naming things, the way I approach copywriting is actually in a very programmatic way. It's leaning on frameworks. It's leaning on patterns that I use over time.

I know, Casey, you and I have talked last week about like when I first go to a conference like using open-ended questions versus closed-ended questions and these little kind of communication hacks that I've developed over the years. So now putting those together in a framework to help other people remember that when we're coding, we're not coding for a computer, we're coding through a computer for other people. The computer is just like a code is just a tool. It's a powerful tool. But a lot of times –

CASEY: I have a question for you, Andrea.

ANDREA: Yeah.

CASEY: About that, I find myself switching gears between word land and abstract land. So if I'm coding and I'm not thinking of words, the naming is hard, but sometimes I can switch gears in a different head space. It's like a different me and then I'm naming things really well. Especially if I'm looking at someone else's code, I don't have to be an abstract land; they did that part already. Do you find yourself switching between the two?

ANDREA: Oh, all the time. Yeah, and especially, too, when you're writing prose. There's two different kind of aspects of your brain. There's the creative conceptual side and then there's the analytical rational side and everybody has both. So it does require you to come out of the abstract side in that and then move into more of the analytical space, which is why I love pairing.

I love coding as a group because then that way, it's like the mental model is shared and so, I can stay in my world of naming things really well, or I don't know that we need to be that precise if we try to – like, when I was in one group and they were trying to have a timing thing and it was like down to the millisecond and I was like, “Y'all, we don't need to be that precise. We just need to have this check once every 10 minutes,” and that saved like 6 hours of work. Just being able to say that thing and be the checkpoint.

JESSICA: Yeah. Someone has to be super down in the details of what to type next and it helps to have someone else thinking about it at the broader perspective of why are we doing this?

ANDREA: Yeah, and that's me, typically and I love that role, but it's very different than I think what goes through people's minds when they envision a software developer.

JESSICA: Yeah, maybe they envisioned the things that software developers do that other people don't. Typing curly braces.

ANDREA: Yeah.

MANDO: I still think of that when I'm doing it. When I think of myself as a software developer, I think of myself as the person who hasn't gotten up from their desk in 5 hours and just hunched over, just blazing fast hacking on something that probably is kind of dumb.

[laughter]

But when I don't spend my day like that, I don't really feel exactly like I've been doing my job and it's something that I struggle with because I know that's not the job in its totality by any means and it doesn't mean that I'm not getting good work done.

JESSICA: Not even close to most of the job.

MANDO: Not even close to most of the job, you're exactly right.

JESSICA: Like you said, if you're sitting there for 5 hours by yourself, hunched over your computer, you're probably hacking on something dumb.

MANDO: Right.

[laughter]

JESSICA: We had gotten off on a tangent somewhere without someone to be like, “Why are we doing this again?”

MANDO: Exactly, exactly. Yeah.

ANDREA: Well, and I think that that has been a personal challenge of mine as well. I know there was a really flashbulb moment for me. Scott and I have been running our business together for a couple of years. We had gotten on our first podcast and he was telling our origin story and he used the phrase, “Andrea, she's the non-technical founder.” When I heard it, I was like, “How dare you? I have for 2 years been sitting right next to you,” and then he said, “Well, that's the term you use to describe yourself all the time. We had been in a sales meeting right before I recorded that podcast and that's literally the words you use to introduce yourself. So once you start calling yourself technical, I'll follow suit.”

JESSICA: Wow.

ANDREA: It really made me think and I think some of it is because whenever I go to conferences, I don't look like other people who code especially 12 years ago. I don't talk like the people who are typically stereotypical developers and the first question I would get asked, probably 25 to 40% of the time from people I met were, “Hi! Are you technical, or non-technical?”

JESSICA: Really?

ANDREA: Yeah.

MANDO: Ugh.

JESSICA: Huh.

ANDREA: And that would be the first thing out of the gate. At the time, I didn't have the kind of mental awareness to go, “I'm at a technical conference. I think you can assume I'm technical.” The fact is I was scared to call myself technical and over the years, I'm just like, “What does that mean to be technical and why do we define people by you are either technical, or you have nothing?” Non-technical, you have zero technical skills, you don't belong.

JESSICA: So after you had that conversation with Scott, did you switch to calling yourself technical? Did you change your language?

ANDREA: It has been a journey. I became very conscious of not using non-technical. I'll sometimes then say like, “I struggle with syntax and I'm really, really good at these things.” When I phrase things that way, or “I have engineers who are so much better and have much deeper expertise in Docker and Kubernetes than I do. I'm really good at explaining the big picture and why this happens.”

So it becomes, I think what we do in software is that because we're so used to thinking in binaries, because that's the way we need to make our code work—true/false, if/else, yes/no—and that pattern naturally extends itself into human relationships, too. Because I know that every single person who asked me that question in no way was trying to be rude, or shut me out. I know that the intention behind it was kind and trying to be inclusive. But from my perspective, when half the people walk up to you and go, “Do you belong here?” Then it's like, “I don't know. Do I belong here?”

JESSICA: Yeah.

ANDREA: So that's an example of how, if you're at a conference saying, “What brings you here?” That's very open-ended and then it gives everybody the chance to say what brings them here and there's no predefined, “Do you fit in this bucket, or that bucket? Are you part of us, or are you part of them?”

JESSICA: It's open to surprise.

ANDREA: Mm hm and I think that's something that I am really good at. That's my superpower is let's see the complexity and then let's see the patterns and let's figure out how we can all get good work done together. But you can't see the complexity unless you take a step back.

JESSICA: Yeah, and yet Scott noticed that when you are thinking that way, you are thinking like a programmer. Because while software starts by getting us used to thinking in binaries—I should say programming.

ANDREA: Yeah.

JESSICA: It’s just thinking of binaries, as soon as you get up to software and software systems, you have to think in complexity.

ANDREA: Yeah.

MANDO: And like you were saying, Andrea, I find myself nowadays better recognizing when I'm falling into that trap when I'm not talking about work stuff. When I find myself saying, “Well, it's this, or it's this.” It's like, “Is it really this, or this?”

JESSICA: Are these the only options?

ANDREA: Yeah.

MANDO: Yeah. Do I have to eat Thai food, or pizza tonight, or could I just eat ice cream, or a salad, or…?

[laughs]

ANDREA: Yeah.

MANDO: You know what I mean? It's a silly example, but I don't know, there's something about doing this for a while that I find that kind of this, or that thinking wiring itself into my brain.

JESSICA: Yeah.

ANDREA: Yeah. Well, and I think that that's normal and that's human. We operate on heuristics. There's the whole neurons that fire together wire together and if you're spending the majority of your time in this thought pattern, adopting something else can be a challenge.

So to me, it's like trying to describe how the way I navigate the world in being able to name things well and being able to talk to new people, connect dots, see patterns that I rely on frameworks just as much as I do when I code and trying to figure out what are those things. What are those things?

JESSICA: Yeah, because you don't have to import that top level file from the framework in order to use it. So it's not explicit that you're using it.

ANDREA: Exactly. Yeah, exactly. So that's been my challenge is that as Scott is like, “Well, help me understand.” I'm like, “I, uh. I don't know. I do this.” That was where I nailed on empathy as really critical and it's been fascinating because when I first started about 5 years writing and talking about empathy in software, the first thing I noticed were all the patterns.

I was like, “A really well-written commit message, that's empathy.” That is taking the time to document your rationale so that it's easier for somebody behind you. Refactoring a method so that it's easy to read, deleting the dead code so that it's less burdensome, even logging. Looking at logging in C versus Ruby, it's night and day.

JESSICA: Help messages.

ANDREA: Yeah. There's a little moment.

MANDO: Non-happy path decisions in code. Guardrails. All that stuff.

ANDREA: Yeah. So I started thinking in terms of communication artifacts. All of these little things that we're producing are just artifacts of our thinking and you can't produce a communication artifact unless you are considering a perspective. What I noticed, of the perspective, is that a lot of software developers had been trained to take was that of the compiler. I want to make the compiler happy. I want to make the code work.

That's a very specific practice of perspective taking that is useful if you're imagining okay, we don't have to get rid of that and we need to add the recognition that the perspectives taking needs to go the compiler into who will be interacting with what you're creating and that is on both the other side of the UI, if there is one, or working on the code that you've written maybe six months from now and that can be your future self.

And then also, who will be impacted by the work that you create, because not everybody who is impacted by the decisions that you make will be directly interacting with and when I'm writing content, or that is the framework is getting to know the audiences really well, doing good qualitative research. So that's kind of the difference between the open-ended versus closed-ended questions.

Then being able to perspective change and then along the way, there are little communication hacks, but just thinking about every single thing that you produce—and no, I have not come across a communication artifact, or a thing that is produced while coding that is not somehow rooted in empathy.

JESSICA: Because it's communication and you can't communicate – [overtalk]

ANDREA: It’s all communication.

JESSICA: At all without knowing what is going to be received and how that will be interpreted.

ANDREA: Yeah. Similar to test-driven development, where we're framing things in terms of unit tests and just thinking about the test before we write the code. In the same way, we're thinking about the perspective of other people—we can still think of the compiler—and anchoring our decisions on how it will impact other people.

JESSICA: It's making the compiler happy. That's just table stakes. That's absolute minimum.

ANDREA: Yeah. Well, it's been fascinating because this part of this project. So I'm writing a book now, which is super exciting and by far, the hardest thing I've ever done. But one of the things that, because I'm curious, I'm like, “Why? How did we get here? How did we get here where, by all objective measures, I should have been able to go into computer science without a problem and feel like –?”

JESSICA: Think of yourself as technical without a problem.

ANDREA: Yeah. Why do I still struggle and why did we extract empathy out of this? So looking at the history of it has been fascinating because as the computer science industry grew, there was a moment in the mid-60s.

There was a test, like a survey, that went out to just under 1,400 people called the Canon Perry vocational test for computer programmers. It was vocational satisfaction, I think. But it was measuring the satisfaction of programmers and they were trying assess what does a satisfied programmer look like.

There were many, many problems with the methodology of this, including the people who they didn't define who a programmer was, the people self-defined. So it's like, if you felt like you were programmer, then you were a programmer, but there was no objective. Like, this is what a programmer is prior to selecting the audience, the survey respondents and then when they evaluated the results, they only used professional men. They didn't include any professional women in their comparison study.

So the women in the study, there are illustrations and the women are not presented as professionals, they are presented as sex objects in a research paper. The scientific programmers, they're the ones who get the girl and she's all swooning. The business programmers are very clearly stated as less than and they're shy. The girl is like, “I don't want you.”

JESSICA: That have like comics, or something?

ANDREA: It was comics, yeah. They had like comic illustrations in there. Okay, it's a survey, what's the big deal? Well, from 1955 through the mid-90s, there was an aptitude test from IBM called the Programmer Aptitude Test, the PAT. In there, Walter McNamara from IBM, who created it, went out, had empathy, and was like, “Okay, let's talk to our customers, what does a good programmer look like,” and determined that logical reasoning was the number one attribute. Okay, sounds good.

But then he said, “Well, if logical reasoning is the most important attitude, then we need to create a timed 1-hour math test.” What's interesting to me is that in that, there is a logical fallacy in and of itself, called a non-sequitur, [chuckles] where it's like all humans are mammals, bingo a mammal. Therefore, bingo is a human. That's an example of a non-sequitur.

That's what happened where it was determined logical reasoning is important to computer science and programming. All mathematics is logical reasoning. Therefore, mathematics is the only way to measure the capability that somebody has for logical reasoning. That, saying, “Okay, we don't care about communication skills. We don't care about empathy. We don't care about any of that. Just are you good at math?”

And then the PAT’s study—I've been diving into the bowels of the ACM and looking at primary resource documents for the past several months—and there was an internal memo where Charles McNamara referred to the Canon Perry study in 1967 and said, “The PAT was given to 700,000 people last year and next year, we should incorporate these findings into the PAT,” and the PAT became the de facto way to get into computer science.

So these are decisions that were made long before me and so, what you end up getting then – and then also in 1968, there was what's called, there was a NATO conference on software engineering and they said, “We really need to bring rigor into computer science. We need to make this very rigorous.” Again, there were no men at this conference. It was about standards and Grace Hopper wasn't even invited, even though she was like – [overtalk]

JESSICA: There were no women in the conference.

ANDREA: There were no women.

JESSICA: No non-men.

ANDREA: No non-men, yes. So you start to see stereotypes getting built and one of the stereotypes became, if you look like this and you are good at math, then you are good at programming. I'm very good at logical reasoning, but I struggle to do a time capsule. I have ADHD and that is something that's very, very, very challenging for me. So that coupled with and then you get advertising where it's marketed, too.

MANDO: Yeah.

ANDREA: So we need to undo all of this. We can recognize, okay, we can refactor all of this, but it takes recognizing the complexity and how did it all come to be and then changing it one thing at a time.

CASEY: A lot of what you've just been talking about makes me think about Dungeons and Dragons and Skyrim for a little nerdy segue.

ANDREA: Yeah.

CASEY: You have skill trees. You could be a really, really good warrior, very good at math, very good at wielding your sword, and then if you measure how good you are at combat by how big your fireball spell can be, how many you can shoot, how accurate you are, you're missing that whole skill tree of ability, of power that you have.

ANDREA: Yeah.

MANDO: What I find so fascinating is when I was going through the computer science program that I never finished and this was like a million years ago. When I was in college, there was a very specific logical reasoning class that you had to take as part of the CS program at UT. But it wasn't a math class, it was a philosophy class and I think that's pretty common that logistics studies fall under schools of philosophy, not the schools of mathematics. So it was really interesting to me that these dudes just completely missed the mark, right? [laughs]

ANDREA: It is the definition of irony and not Alanis Morrissette kind of way, right?

[chuckles]

I think that's the thing it's like – and this isn't to say the Walter McNamara was a bad person like, we all make mistakes. But to me, again, this is about impact and if one, or two people can have the ability to create a test that impacts millions of people across generations to help them feel whether, or not they belong in even contributing to building software.

Because I always felt like I was a user of software—I was always a superuser—but for some reason, I felt like the other side of the interface, the command line, it was like Oz. It was like that's where the wizards live and I'm not allowed there. It's like, how do we just tear down that curtain and say, “Y'all, there is no – no, this was all built on like false assumptions”? How do we have a retrospective and say, “When we can look at a variety of different perspectives, then we get such stronger products.” We get such stronger code. We minimize technical debt in addition to hopefully, staving off biases that get built into the software.

I think it's very similar of human systems, very similar to software systems. It's like, how can we roll back? If we make a mistake and it impacts human systems, how can we fix that as fast as possible, rather than just letting things persist?

JESSICA: When you're talking about who can be a good software developer, when you're talking about who is technical, who is valuable, you don't want rigor in that!

ANDREA: Right!

JESSICA: That's not appropriate.

ANDREA: Yeah.

JESSICA: You want open questions.

ANDREA: Yeah, and that is exactly what happened, was people conflate rigor and data with accuracy. There's a bias towards if it's got numbers behind it, it must be real, but you can manipulate data just as much as you can manipulate other things.

So the PAT then said, “Okay, well, if you can't pass the PAT, then we'll create all of these other types of tests, so you could be a console operator, or you could be a data analyst.” What's fascinating is when you go back, the thing that was at the very bottom of the Cannon Perry survey, in terms of valuable development activities, was software maintenance.

JESSICA: And that's everything now.

ANDREA: Yeah!

JESSICA: Back then, they didn't have a lot of software.

MANDO: Yeah.

JESSICA: They didn’t have open source libraries. If they needed something, they wrote it.

ANDREA: But the stereotypes persist.

JESSICA: Yeah.

MANDO: 100%.

ANDREA: The first evidence I found, again, was in 1967. There was a study of 12 people, all of whom were trainees at a company, which that would be a wild – they hadn’t even – [overtalk]

JESSICA: So this is like even less than interviewing your grad students.

ANDREA: Well, yeah.

JESSICA: Or your undergrads for your graduate research paper, yes.

ANDREA: They measured how quickly someone could solve a problem and they ranked them, and then they made the claim that you can save 25 times—this is the first myth of the 25x developer. Well, it got published in the ACM and then IBM picked it up and then McKinsey picked it up, and then it’s just, you get the myth of the full-stack unicorn who's going to come in and save everything!

What's interesting is all of these things go back and I think they were formed out of good intention in terms of understanding our world and we understand now, exactly like you said, Jess. That's not the right way to go about it because then people who are really needed on software teams don't feel like they belong and it's like, “Well, do you belong?”

JESSICA: That's an outsized impact for such a tiny study.

ANDREA: Yeah. So that gets me thinking, what kinds of things am I doing that might have an outside impact?

JESSICA: And can we make that impact positive?

ANDREA: Yeah, and when we find out that it wasn't, can we learn from our mistakes? I think one of the things, too, is taking the idea of as people are coding. It's like, “Well, who's actually going to read this?” That's something I hear a lot.

I used to feel that way about all tags. I’m like, “Who actually reads all tags?” But then my friend, Taylor, was in a car accident and lost his vision. and he was like, “I absolutely need all tags,” and I’ll tell you, that changed everything for me. Because it went from this abstract, “I have to check this box. I have to type something in, and describe this photo” to “I care about my friend Taylor and how can I make this experience as best for him as possible?”

That is empathy because in order to have empathy, you have to connect with a single individual. Empathy is – and actually, when you do form empathy for a group, you get polarization. So empathy cuts both ways. It can be both very positive, but also very – [overtalk]

CASEY: [inaudible] on the individual goes a long way. So for our discussion here, I can share an individual I've been talking to about this kind of problem. I have a friend who's a woman trying to get her first software developer role and she has to study how to hack the coding interview for a lot of the places where she wants to work, which is literally studying algorithms that you probably won't use in the job.

I had an interview a few years ago that was the Google style algorithms interview for a frontend role. Frontend developers don't write algorithms, generally. Not unless you're working on the core of the framework maybe. It was completely irrelevant. I rejected them. I think they rejected me back, too probably.

[laughter]

But I wouldn't work there because of the hiring process. But my friend, who is a woman in tech trying to get in, doesn't have that kind of leeway to project. She wants to get her first job whoever it is – [overtalk]

MANDO: She wants a job, yeah.

CASEY: That is willing to use the bias system like that and to hack that system to study it specifically how to get around it, which isn't really helping anyone.

ANDREA: Yeah.

CASEY: So how can we help reform the system so she doesn't have to do that kind of thing and so, people like her don't have to, to get into tech? I don't know, my boycotting that one company is a very small impact; how do we get a company's hiring practices to change is a hard problem.

ANDREA: It is a very hard problem. I can share what we are doing in Corgibytes to try to make a difference.

I think the first thing is that in our hiring process, we have core values mapped to them and these are offshoots of our main core values, one of which is communication is just as important as code. So we have that every single applicant will get a response and that seems so like, duh, but the number of people who are here who are just ghosted, submit an application and it goes out into the ether. That is, in my opinion, disrespectful.

We have an asynchronous screening interview, so it’s an application and it's take your time, fill it out, and it's questions like, “What's an article you found interesting and why?” and “What do you love about modernizing legacy code?” Some people need that time to think and just to formulate an answer and so, taking some of that pressure off, and then at the end of our – we have all of our questions mapped to our core values.

I'm still trying to figure out how we can get away from more the dreaded technical interviews, but we don't use the whiteboard, but we also have a core value of anything that someone does for us, in terms of whether they show up for an interview, they will walk away with just as much benefit. They will have an artifact of learning something, or spec work is I think, immoral to some of these core things.

So we use Exercism for us, so Katrina Owens, as a way of like, “Okay, show us a language that you're like really familiar with.” And then because with what we do, you just get tossed into if it’s like, “Okay, let's pick Scala.” It's like you've never tried functional programming before, but then just, it's more of seeing the mindset. Because I think it's challenging because we tried getting rid of them all together and we did have some challenges when it came to then client upper-level goals and doing the job.

So it's a balance, I think and then at the end of our interviews doing retrospectives telling the candidate, “Here's what you did really well in this interview, here's where it didn't quite land for me,” because I think interviewing is hard and like you said, Casey, especially now post-COVID, I think more and more people have the power to leave jobs. So I think the power, especially in software development, for people who have had at least their first position, they have a lot more power to walk out the door than they did before.

So as an employer and as somebody who's creating these, that's what I'm doing and then if we get feedback and the whole idea with empathy is you're never going to be able to be perfect. Because you don't have the data for the perspective of every single person, but being open and listening and when you do make mistakes, owning up to them, and fixing them as fast as possible. If we all did that, we can make a lot of progress on a lot of fronts really fast.

CASEY: I'm so glad your company has those good hiring practices. You're really thinking about it, how to do it in a supportive, ethical, and equitable way. I wonder, we probably don't have the answer here today, but how can we get more companies to do that?

I think you sharing here might help several companies, if their leadership are listening. and that's awesome. Spreading the message, talking about it more—that's one thing. Glad we're doing that.

MANDO: Yeah. The place that I work at, we’re about to start interviewing some folks and I really like the idea of having a retrospective with the candidate after maybe a couple of days, or whenever after the interview and taking the time, taking the 30 minutes or whatever, to sit down and say, “If I'm going to take time to reach out to them anyway and say, ‘You're moving on to the next round,’ or ‘We have an offer for you, or not,’ then I should be willing to sit down with them and explain why.’”

ANDREA: Well, I think the benefit goes both ways, actually. We do it right in our interviews. So we actually say the last 15 minutes, we're going to set aside on perspectives.

MANDO: Oh wow, okay.

ANDREA: So we do and that's something that we prep for ahead of time. We get feedback of what went well [chuckles] and what we can do better and what we can change.

MANDO: Yeah.

ANDREA: Because otherwise, as an employer, it's like, I have no idea. I'm just kind of going off into the ether, but then I can hear from other people's perspectives and it's like, okay and then we can change things. But that's an example of, we think of employer versus employee and it's like that's another dichotomy. It's like no, we're all trying to get good work done.

JESSICA: Andrea, how do you do performance reviews?

ANDREA: We're still trying to crack that, but there's definitely a lot of positive psychology involved and what we are trying to foster is the idea of continuous performance, or continuous feedback is what we call it. So we definitely don't do any kind of forced ranking and that's a branch of things that have contributed to challenges. We have one-on-ones, we check in with people, but a lot of it, I think is asking people what they want to be doing, genuinely. As a small company, we're like 25 people. I think it's easier in a small company, but part of it is – and we were constantly doing this with ourselves, too. My business partner was like, “I really want to try to be the CEO. I've always wanted to be the CEO.” So I stepped back actually during COVID.

We focus on being a really responsive team and so, then that way, it's less about the roles. It's less about rigidity. There's a really great book in terms of operations called Brave New Work by Aaron Dignan. It has a lot of operational principles around this. Team of Teams is another really good one. But just thinking through like, what's the work that needs to be done, how can we organize around it, and then thinking of it in terms of more of responsibilities instead of roles.

JESSICA: I want to think of it as a relationship. It's like, I'm not judging you as a developer, instead we’re evaluating the relationship of you in this position, in this role at this company.

ANDREA: Yeah.

JESSICA: How is that serving the company? How is that serving you?

ANDREA: Yes, and I think that's a big piece of it is – and also, recognizing the context is really important and trying to be as flexible as possible, but then also recognizing constraints. So there have been times where it's like, “This isn't working,” but trying to use radical candor as much as you can, that's something we've been working on. But trying to give feedback as early and as often as possible and making that a cultural norm as to the, “Oh, I get the 360 feedback at the end, twice a year,” like that.

JESSICA: Yeah, I'm sorry, if you can't tell me anything within two weeks, don't bother.

ANDREA: Yeah. But one example is like we've fostered this and as a leader, I want people who are going to tell me where I'm stepping in it and where I'm messing up. So I kind of use – [overtalk]

JESSICA: Yeah, at least that retrospective at the end of the interview says that.

ANDREA: Mm hm, but even with my staff, it’s like – [overtalk]

JESSICA: [inaudible] be able to say, “Hey, you didn’t send me a Google Calendar invite,” and they'd be like, “Oh my gosh, we should totally be doing that.” Did anybody tell them that? No!

ANDREA: Yeah, totally. So I don't claim to have the answers, but these are just little experiments that we're trying and I think we really lean on the idea of continuous improvement and marginal gains.

Arthur Ash had a really great quote, “Start where you are. Use what you have. Do what you can.” I think that's the thing, the whole point of the empathy during development framework is that if you're a developer working on the backend writing a nice commit message, or giving quality feedback on a pull request, instead of just a “Thumbs up, looks good to me.”

That's a small act of empathy that you can start doing right away. You don't need to run it by anybody, really, hopefully. If you do, that's a problem [chuckles] your manager and we've seen that. But there are small ways that you can be empowered and leaning into those small moments, doing it again and again, and then creating opportunities to listen. Because empathy, I think the other thing is that people tend to think that it's a psychic ability. You're either data, or your Deanna Troi.

CASEY: Jamil Zaki, right?

ANDREA: Yeah, the Roddenberry effect. Jamil Zaki, out in Stanford, coined that. I think that's the thing; I've always been told I'm an empath, but I don't think it's telepathy. I think it's just I've gotten really good at spotting patterns and facial recognitions as opposed to Sky. He can just glance and go, “Oh, you're missing a semicolon here.” That is the same skill, it's just in a different context.

CASEY: I love that parallel.

JESSICA: Yeah.

CASEY: Recognizing small things in facial expressions is like noticing missing semicolons.

M: Mm hm. [laughs]

CASEY: That's so powerful. That’s so vivid for me.

MANDO: Yeah. Going back, that made what something that you said earlier, Andrea really click for me, which is that so many people who are professional software developers have this very well-developed sense of empathy for the compiler. [laughs]

ANDREA: Yeah.

MANDO: Right, so it's not that they're not empathetic.

ANDREA: Yes!

MANDO: They have learned over their career to be extremely empathetic, it's just for their computer. In the same way, you can learn to be empathetic towards your other teams, towards your DevOps group, towards the salespeople, towards anybody.

ANDREA: The flip side of your non-technical is you're not good with people because Scott got this all the time. He's like, “You're good with machines, but you're not good with people.” When he told me that, I was like, “I've known you since we were 11, you're incredibly kind. I don't understand.”

So in some ways, my early journey here, I didn't come with all the baggage and so, there is this, like, this industry is weird. [laughs] How can we unpack some of this stuff? Because I don't know, this feels a little odd. That's an example and I think it's exactly that it's cultural conditioning and it's from this, “You're good with math, but we don't want you to be good with people.” If you're good with people, that's actually a liability. That was one of the things that came out of the testing of the 60s, 70s, 80s, and early 90s.

MANDO: I can't wait till this book of yours comes out because I'm so curious to read the basis of all these myths that we have unconsciously been perpetuating for years and I don't know why, but there is this myth, there are these myths. Like, if you're technical, you're not good with people and you're not – you know what I mean? It’s like, I can't wait to read it.

ANDREA: You can go to empathyintech.com. You can sign up for the newsletter and we don't email very often. But Casey actually helps me run a Discord channel, too, or Discord server. So there's folks where we're having these conversations and it doesn't matter what your role is at all.

MANDO: Yeah.

ANDREA: Just let's start talking to each other.

JESSICA: Andrea, that's beautiful. Thank you. That makes this a great time to move to reflections. At the end of each episode, we each get to do a reflection of something that stood out to us and you get to go last.

ANDREA: Awesome.

MANDO: I can go first. I've got one. The idea that empathy is being able to view and identify other perspectives is one that is something that I'm going to take away from this episode.

I spent a lot of my career as a software developer and spent another good chunk of my career as someone who worked in operations and DevOps and admin kind of stuff. There's this historic and perpetual tug of war between the two and a lot of my career as a systems administrator was spent sitting down and trying to explain to software engineers why they couldn't do this, or why this GraphQL query was causing the database to explode for 4 hours every night and we couldn't live like that anymore. Stuff like that.

To my shame, often, I would default to [laughs] this idea that these software engineers are just idiots and that wasn't the case at all. Well, probably [laughs] not the case at all. Almost always it wasn't the case at all. Anyway, but the truth of the situation is probably much closer to the idea that their perspective was tied specifically to the compiler and to the feature that they're trying to implement for their product manager, for customer X, or whatever. And they didn't have either the resources, or the experience, or the expertise, or whatever that was required to add on the perspective of the backend systems that they were interacting with.

So maybe in the future, a better way to address these kinds of situations would be to talk about things in terms of perspective and not idiocy, I guess, is the…

ANDREA: Yeah, a really powerful question there is what's your biggest pain point and how can I help you alleviate it? It's a really great way to learn what somebody's perspective is to get on the same page.

MANDO: Yeah, like a lot.

JESSICA: Nice. I noticed the part about how a lot of the help happens when you have empathy for the individuals who aren't on a happy path, who aren't the great majority of the people using the software, or the requests that come through your software. It's like that parable, there's a hundred sheep and one of them goes astray and the shepherd is going to leave the ninety-nine—who are fine, they're on the happy path, they're good—and go help the one. Because some other day, it's going to be another sheep that's off the happy path and that one's going to need help and that's about it.

MANDO: Yeah. Today you, tomorrow me, right? That's how all this works.

CASEY: The thing I'd been picking up is about feedback. Like, the best way to develop empathy for someone else is to get feedback, to get their perspective somehow. I've done retros at the ends of meetings, all the meetings at work I ever do. I even do them at the end of a Pomodoro session. A 25-minute timer in the middle of a pairing day, I'll do them every Pomodoro. “Anything to check in on? No? Good. Okay.” As long as we do. But I've never thought to do it during the interview process. That is surprising to me.

MANDO: Yeah.

CASEY: I don't know if I can get away with it everywhere. The government might not like it if I did that to their formal process.

[laughter]

Maybe I can get away with, but it's something I'll think about trying. I would like feedback and they would like feedback—win-win.

MANDO: Yeah, I've never done it either and it makes perfect sense. I have a portion, unfortunately, in my interviews where I say right at the beginning, “This is what's going to happen in the interview,” and I spend 5 minutes going through and explaining, we're going to talk about this, we're going to talk about that, or just normal signposting for the interview. It never once has occurred to me to at the end, say, “Okay, this is what we did. Why don't you give me some feedback on that and I give you some feedback about you?” That makes sense.

ANDREA: Awesome. For me, I have been wanting to come on your show for a really long time. I was telling Casey. [chuckles]

JESSICA: Ah!

ANDREA: I was like, “I love the mission of expanding the idea of what coding is.” So I just feel very honored because for the longest time, I was like, “I wonder if I'm going to be cool enough one day to –” [laughs]

JESSICA: Ah! We should have invited you a long time ago.

ANDREA: Yeah. So there's a little bit of fangirling going on and I really appreciate the opportunity to just dive a little bit deep, reflect, and think. As somebody who doesn't mold, it's nice to get validation sometimes that the way I'm thinking is valuable to some people. So it gives me motivation to keep going.

JESSICA: Yeah. It's nice when you spend a lot of energy, trying to care about what other people care about, to know that other people also care about this thing that you care about.

ANDREA: Yeah.

JESSICA: Thank you so much for joining us.

ANDREA: Thank you for having me!

MANDO: Thank you.

ANDREA: The fastest way to reach out to me and make sure that I see it is actually to go to corgibytes.com. Corgi like the dog, bytes, B-Y-T-E-S, .com and send an email on the webform because then that way, it'll get pushed up to me. But I struggle with email a lot right now and I'm on Twitter sporadically and I'm also on –

MANDO: That’s good. The best way to do that.

ANDREA: I am a longform writer. I'm actually really excited that I have a 100,000 words to explain myself. I do not operate well in the 140-character kind of world, but I'm on there and also, on LinkedIn.

And then the book website is empathyintech.com and there's a link to the Discord channel and some deeper articles that I've written about exactly what empathy in tech is and what empathy driven development is. I'm writing it with my friend, Carmen Shirkey Collins, who is another copywriter who is now in tech over at Cisco, and it's been a joy to be on a journey with her because she's super smart and has great background in perspective, too.

JESSICA: And if you want to work on meaningful, impactful legacy code in ensembles, check out Corgibytes.

ANDREA: Yeah.

JESSICA: And if you want to talk to all of us, you can join our Greater Than Code Slack by donating anything at all to our Greater Than Code Patreon at patreon.com/greaterthancode. Thank you, everyone and see you next time!

Special Guest: Andrea Goulet.

Support Greater Than Code