Podcast appearances and mentions of andrea goulet

When did soft skills like empathy become deprioritized in the tech industry? My guest today shares a little history lesson on how that happened and why initially those soft, human skills were always a vital part of successful innovation and technology before they got separated. Only now are they finding their way back to each other in software development and programming to solve the 21st century's most complex challenges. Today, I talk with Andrea Goulet. We talk about how soft skills like empathy lost favor in technology curricula, and how she built her business centered around empathy before it successfully merged with another company. She talks about the research she uncovered on programming models that parallel human communication. And we discussed why the current AI landscape is moving so fast but that her models can be used to ensure we intentionally apply empathy to deal with long-term consequences while still gaining short-term benefits. To access the episode transcript, please search for the episode title at www.TheEmpathyEdge.comKey Takeaways:Investing in empathetic communication will positively impact any team you're on. Having a good understanding of empathy drives any industry.80 to 90% of our miscommunications happen at the concept level because you can say something and someone can understand the word but might think of it as a different thing.The four dimensions of human communication and our ability to pivot and understand one another are: catch, collect, connect, and communicate. "Whether we're talking about software, building pyramids, or finding new ways to hunt and take down the mammoth, empathy is the mechanism that enables us to communicate, collaborate, and solve complex problems together." — Andrea Goulet Episode References:Ilana Ben-Ari: How The Empathy Toy is Changing the WorldFrom Our Partner:SparkEffect partners with organizations to unlock the full potential of their greatest asset: their people. Through their tailored assessments and expert coaching at every level, SparkEffect helps organizations manage change, sustain growth, and chart a path to a brighter future.Go to sparkeffect.com/edge now and download your complimentary Professional and Organizational Alignment Review today.About Andrea Goulet: Co-Founder, CorgiBytes, Founder, Empathy in TechAndrea Goulet is on a mission to integrate empathy into the software industry. She is a sought-after international keynote speaker, experienced software executive, and award-winning industry leader. Her expertise centers on using empathy and effective communication to modernize legacy and mission-critical software systems.Through her online courses, Andrea has taught over 50,000 students how to level up their empathy and communication skills to create better software. She is the author of the forthcoming book, Empathy-Driven Software Development, and the founder of Empathy in Tech, an online community where code and compassion connect.Connect with Andrea:Website: andreagoulet.comEmpathy in Tech: empathyintech.comLinkedIn: linkedin.com/in/andreamgouletHer coming book: Empathy-Driven Software Development Connect with Maria:Get the podcast and book: TheEmpathyEdge.comLearn more about Maria and her work: Red-Slice.comHire Maria to speak at your next event: Red-Slice.com/Speaker-Maria-RossTake my LinkedIn Learning Course! Leading with EmpathyLinkedIn: Maria RossInstagram: @redslicemariaX: @redsliceFacebook: Red SliceThreads: @redslicemariaAchieve radical success putting empathy into action with Businessolver. Techlology with heart, powered by people. https://www.businessolver.com/edge

Have you noticed people cannot talk to each other? Have you noticed there is a them versus us? Andrea Goulet has studied empathy and she has studied it in a way I don't think I've ever seen before and she's going to share her framework with us. Andrea Goulet is on a mission to make empathy a core technical skill in software development.  She is a sought-after international keynote speaker, experienced software entrepreneur, and award-winning industry leader. Her expertise centers on using empathy and effective communication to modernize legacy and mission-critical software systems.  She is currently working on her first book, Empathy-Driven Software Development, where she aims to provide detailed mechanisms and system schematics of empathy's inner workings in a way that makes sense to engineers. Andrea started her career in strategic communications where she had a technical understanding about empathy and organizational psychology. She was approached by a friend to help build a software company and lead it as the CEO.  They landed on doing consulting together, and also ended up falling in love with each other. (Hollywood screenwriter, where are you?) “What we ended up having in building this business was the stereotypical dynamic of the salesperson and the engineer,” says Andrea. “They don't get along professionally. I did not understand how his brain worked. I had never worked in software.” It was 2009, and they wanted to have a software company where empathy was at the core of the organization. She says they were advised not to do that to avoid being “laughed out of the industry.” Andrea doubled down. “[Empathy] was the thing that drove business profitability, that drove business efficiency, that contributed to organizational effectiveness,” says Andrea. And it wasn't just in working with clients – empathy was needed in her daily operations with her now husband and business partner, Scott. She recalls an incident where she needed to pull Scott into a client meeting, and walked over to his desk. Her ask pulled him out of his work process that led to a visceral reaction. When they sat down to discuss why he was so upset, he likened it to the movie Inception – saying he was nine levels down, and the action of interrupting him had ripped him from the solution he was on the cusp of solving.  The feeling of being completely ripped out of something Andrea could understand. And together they came up with a way to move forward, which became the subject of Andrea's keynotes at software development conferences. Over the course of her work, Andrea realized there was no consensus as to what empathy meant. Phrases like walking in someone else's shoes, treating people how they want to be treated were often heard.  “The reason that we have evolved empathy as a species is so that we work together. And as a species we don't go extinct. So we are a hyper social species,” says Andrea. “Empathy is the mechanism that enables collaboration.” She defines empathy is a functional system of emotion, cognition, regulation, and motivation that is influenced by external factors such as culture, context, capacity, and skill. To make empathy more concrete; she uses a model called structured reappraisal.  A reappraisal is a psychological term for taking a beat before you act. And the pause can be learned and practiced. What to do once you pause is where the structure comes in. The three rules are: collect, connect, and communicate. Listen in for ways to practice this framework. Empathy can help us navigate through all of those different systems and then create something that is more effective through these experiments and through implementing these improvements. But you can't get there unless both people are willing to do it. Connect with Andrew Goulet : https://andreagoulet.com  Other GoG episodes you might want to check out: Top Strengths of the Highly Sensitive Entrepreneur: https://sarahwalton.com/highly-sensitive-person/  The Art of Self-Control: https://sarahwalton.com/take-back-self-control/  You can check out our podcast interviews on YouTube, too! http://bit.ly/YouTubeSWalton   Thank you so much for listening. I'm so honored that you're here and would be so grateful if you could leave a quick review on Apple Podcasts by clicking here, scrolling to the bottom, and clicking “Write a review.” Then we'll get to inspire even more people! (If you're not sure how to leave a review, you can watch this quick tutorial.)

CTO Series: Andrea Goulet On How To Lead with Empathy in Software Development In this special BONUS episode of the CTO Series, Andrea Goulet, an innovative software executive, shares her mission to change the tech industry by making empathy a core technical skill. Andrea's insights reveal how empathy can transform leadership, foster collaboration, and drive success in software development. Through personal stories and practical tips, she illustrates the power of empathy in navigating complex challenges, from aligning mental models to enhancing communication between teams and leaders. Defining Leadership Through Empathy "Empathy isn't just credible in the software industry; it's crucial for innovation and collaboration." Andrea reflects on her journey from a communications background where psychology played a pivotal role, to becoming a software executive who champions empathy. Despite initial skepticism from industry consultants, Andrea stuck to her belief that empathy was essential for success in tech. She shares a transformative experience with Scott Hanselman that highlighted the importance of understanding mental models and developing new communication strategies. This experience solidified her approach to leadership, emphasizing empathy as a vital skill for effective collaboration. "Pause, reappraise, and think before you act – empathy in action is the key to navigating complex interactions in tech." Enhancing Team Dynamics Through Empathy "Developers can be as empathic as business leaders, breaking down traditional communication barriers." Andrea delves into the importance of empathy between teams and their leaders, particularly when dealing with mismatched mental models. She discusses the protocols she has developed based on real-life situations, which prioritize empathy in decision-making and feedback processes. By advocating for her team members and facilitating conversations between executives and developers, Andrea demonstrates how empathy can lead to more effective problem-solving and collaboration. "Facilitate conversations that shift from confrontation to collaboration – empathy is the bridge to solving shared problems." Bridging Communication Gaps in Agile Environments "The communication infrastructure is the 'plumbing' that allows information to flow seamlessly across your organization." Andrea explains how the book Team of Teams by General Stanley McChrystal influenced her understanding of agile methodologies. Struggling with the lingo of Agile, she found clarity in McChrystal's discussion of complex systems and the importance of managing interdependencies. Andrea emphasizes the need for a robust communication infrastructure to ensure that information flows freely within an organization, enabling teams to respond quickly to changing circumstances and align their efforts with broader business goals. "Build communication loops that enable agility – the right infrastructure supports the flow of information and decision-making." [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Andrea Goulet Andrea Goulet is on a mission to change the way the world thinks about empathy by leading a scientific revolution and making empathy a core technical skill for all technologists. She is a sought-after international keynote speaker, experienced software entrepreneur, and award-winning industry leader. Her expertise centers on using empathy and effective communication to modernize legacy and mission-critical software systems. Andrea has taught over 75,000 students through her online courses on empathy and communication. She is the author of the forthcoming book, Empathy-Driven Software Development, and the founder of Empathy in Tech and Legacy Code Rocks, two online communities where code and compassion connect. You can link with Andrea Goulet on LinkedIn.

In this Great Women in Compliance episode, Hemma visits Andrea Goulet, host of the Empathy in Tech podcast and one of the industry's foremost experts on software team communication and collaboration. Andrea has developed a practical framework for teaching empathy as a technical skill for machines and humans through that work. Highlights include a research-backed exploration into empathy as a technical skill, not just a psychic ability. Andrea reminds us that the most important first step for empathy is a pause and reappraisal, and she invites us to mirror the process by which we communicate through software: Collect, Connect, Communicate. In this way, she explains that every domain has a technical and human element. Given that empathy drives decision-making, Andrea shows how empathy, as a technical skill, is inextricably linked to ethical decision-making. About Andrea: Andrea Goulet is one of the software industry's foremost experts on software team communication and collaboration. She has delivered keynotes and training worldwide and empowered over 75,000 people to create better software by approaching empathy as a technical skill. Andrea served as the Co-Founder and CEO of Corgibytes, a software consultancy specializing in modernizing mission-critical software systems for over a decade. Her approach of using empathy to maintain healthy software systems and corporate culture has had an industry-wide impact. In 2017, LinkedIn named her one of the Top 10 People in Software Under 35, and her work has been featured in prominent industry publications. Andrea is currently working on her first book, Empathy-Driven Software Development, through Pearson Publishing. She is the founder of the online community and podcast Empathy in Tech. #GWIC is proud to announce that it has been nominated for the Women in Podcast Awards.  This is a people's choice award and whether you vote for #GWIC or other nominees, we ask that you send the elevator back down by voting. Voting opens August 1, 2024, and details can be found on the #GWIC LinkedIn page at http://www.linkedin.com/groups/12156164 Resources: Join the Great Women in Compliance community on LinkedIn here.

In this Great Women in Compliance episode, Hemma visits Andrea Goulet, host of the Empathy in Tech podcast and one of the industry's foremost experts on software team communication and collaboration. Andrea has developed a practical framework for teaching empathy as a technical skill for machines and humans through that work. Highlights include a research-backed exploration into empathy as a technical skill, not just a psychic ability. Andrea reminds us that the most important first step for empathy is a pause and reappraisal, and she invites us to mirror the process by which we communicate through software: Collect, Connect, Communicate. In this way, she explains that every domain has a technical and human element. Given that empathy drives decision-making, Andrea shows how empathy, as a technical skill, is inextricably linked to ethical decision-making. About Andrea: Andrea Goulet is one of the software industry's foremost experts on software team communication and collaboration. She has delivered keynotes and training worldwide and empowered over 75,000 people to create better software by approaching empathy as a technical skill. Andrea served as the Co-Founder and CEO of Corgibytes, a software consultancy specializing in modernizing mission-critical software systems for over a decade. Her approach of using empathy to maintain healthy software systems and corporate culture has had an industry-wide impact. In 2017, LinkedIn named her one of the Top 10 People in Software Under 35, and her work has been featured in prominent industry publications. Andrea is currently working on her first book, Empathy-Driven Software Development, through Pearson Publishing. She is the founder of the online community and podcast Empathy in Tech. #GWIC is proud to announce that it has been nominated for the Women in Podcast Awards.  This is a people's choice award and whether you vote for #GWIC or other nominees, we ask that you send the elevator back down by voting. Voting opens August 1, 2024, and details can be found on the #GWIC LinkedIn page at http://www.linkedin.com/groups/12156164 Resources: Join the Great Women in Compliance community on LinkedIn here.

AI proves to be great at writing new code, but what are its capabilities when it comes to mending the old one? Today we talk with Ray Myers, a legacy code expert and sceptical enthusiast for AI. With 16 years of software engineering experience, he focuses on collective lessons learned to improve our existing systems and organizations. He tells us where is the place of AI in legacy code mending, whether AI can provide help when editing existing code, how to train AI with up-to-date coding skills, how to utilize AI when writing tests, and much more.  When you finish listening to the episode, make sure to connect with Ray on LinkedIn, visit his website at https://mender.ai, his YouTube channel Craft vs. Cruft, and take a listen to Empathy in Tech - a new podcast cohosted by Ray and Legacy Code Rocks former cohost, Andrea Goulet! Mentioned in this episode: Ray on LinkedIn at https://www.linkedin.com/in/cadrlife/  Craft vs. Cruft at https://www.youtube.com/@craftvscruft8060  Mender website at https://mender.ai  Nopilot.dev at https://nopilot.dev  Empathy in Tech at https://empathyintech.com  Untangler at https://github.com/craftvscruft/untangler   

In this episode we speak with Andrea Goulet about Collaborative Empathy and how it is essential for any cross functional team. Empathy is the mechanism that enables individuals to collaborate in groups to solve complex problems. When teams understand the technical nuances of empathy, they can more easily identify specific practices they can leverage to improve levels of well-being, innovation, and achievement.Andrea Goulet Andrea Goulet is on a mission to integrate empathy into the tech industry. As a sought-after keynote speaker, Andrea is best known for making empathy accessible to analytical skeptics. Her approach to empathy is pragmatic and practical, and she has a particular knack for providing concrete and relevant ways to use empathy for software system health and resilience. --- Send in a voice message: https://podcasters.spotify.com/pod/show/comparativeagility/message

Stephanie is joined today by a very special guest, Andrea Goulet. Andrea founded Empathy In Tech as part of writing her book Empathy-Driven Software Development (https://empathyintech.com/). She's also the founder of the community Legacy Code Rocks (https://www.legacycode.rocks/) and the Chief Vision Officer of two companies: Corgibytes (https://corgibytes.com/) and Heartware (https://www.heartware.dev/) (which provides financial support to keep Empathy In Tech running). Stephanie has strong opinions about the concept of "Makers and Menders" that the Corgibytes folks have written/spoken about, especially around those personas and gender stereotypes. Andrea joins Steph to evolve the conversation and add nuance to the discussion about legacy code/maintenance in our community. This episode is brought to you by Airbrake (https://airbrake.io/?utm_campaign=Q3_2022%3A%20Bike%20Shed%20Podcast%20Ad&utm_source=Bike%20Shed&utm_medium=website). Visit Frictionless error monitoring and performance insight for your app stack. Makers and Menders from Corgibytes (https://corgibytes.com/blog/2015/08/14/makers-vs-menders/) Empathy in Tech (https://empathyintech.com/) Legacy Code Rocks (https://www.legacycode.rocks/) Forget Technical Debt — Here's How to Build Technical Wealth (https://review.firstround.com/forget-technical-debt-heres-how-to-build-technical-wealth) Equal Partners by Kate Mangino (https://bookshop.org/p/books/equal-partners-improving-gender-equality-at-home-kate-mangino/18336353) Sustainable Web Development Episode (https://www.bikeshed.fm/368) Transcript: AD: thoughtbot is thrilled to announce our own incubator launching this year. If you are a non-technical founding team with a business idea that involves a web or mobile app, we encourage you to apply for our eight-week program. We'll help you move forward with confidence in your team, your product vision, and a roadmap for getting you there. Learn more and apply at tbot.io/incubator. STEPHANIE: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Stephanie Minn., And today I'm joined by a very special guest, Andrea Goulet. Hi, Andrea. ANDREA: Hello, thanks for having me. STEPHANIE: So here on The Bike Shed, we like to start by sharing something new in our world. Could you tell us a bit about yourself and anything new going on for you? ANDREA: Yeah, so I have a background in strategic communications, and then kind of made a windy journey over to software. And so, for the past 13 years, I've been focused on modernizing legacy systems. And legacy is kind of a loose term; something you write today can be legacy. But essentially, we kind of help modernize any kind of software, any language, any platform, any framework. And so, over the course of doing that, in the work that I did before I came to software, I had a very technical understanding of empathy and communications and had just done a lot of that. And I just noticed how much that mattered in creating healthy and sustainable codebases. So now I'm kind of taking that experience, and I've got a book contract called "Empathy-Driven Software Development." So I've been working on just diving into a lot of the really deep research. So that's been kind of my focus for the past two years. And it's been really surprising because there were things that were positioned as truths, and then it's like, wait a second, neuroscience is completely upending everything. So it's been a fun learning journey. And I'm excited to share some of the things that I've learned over the years, especially [laughs] in the past two years with this book. So that is the new thing with me. And it's...I was telling you before it just feels like a constant new thing. Anybody who's written a book...it's the hardest thing I've ever done, so... [laughs] STEPHANIE: Yeah, that sounds tough but also kind of exciting because you're learning so many new things that then kind of shape how you view the world, it sounds like. ANDREA: Yeah. Yeah, it really does. And I think I really like diving into the details. And I think what started this was...my business partner, Scott, at the time, really embodied the stereotypical 2010 software developer down to the scruffy beard and dark-rimmed glasses. And what I found incredibly interesting was he had this belief of I'm good with machines, but I'm bad with people. And he just had this really deeply ingrained. On the flip side, I had this belief of, oh, I'm good with people, but I'm bad with machines. I'll never learn how to code. And I found that really interesting. And personally, I had to go through a journey because we went on...it was the first time either of us had ever been on a podcast. So this was about ten years ago. And at the end of the podcast, Scott was the only one on there. And he said, you know, the person asked about his origin story and about our company Corgibytes. And he was like, "Yeah, you know, Andrea is amazing. She's our non-technical founder." And by that time, I had been coding next to him for like three years. And I was like, why the heck would you call me non-technical? And I just felt this...what is it that I have to do to prove it to you? Do I have to actually go get a CS degree? I know I'm self-taught, but does that mean that I'm not good enough? What certificates do I need? Do I need to sit down next to you? Do I need to change my lifestyle? Do I need to look like you? So I was really upset [laughing] and just thinking through, how dare you? How dare you label me as non-technical? And Scott is very quiet and patient, great with people, I think. [laughs] And he listened and said, "I use the words that you use to describe yourself. When we were in a sales meeting right before that phone call, I paid attention to how you introduced yourself, and I pretty much used the same words. So when you call yourself technical, I will too." That shattered my world. It shattered my identity because then it put the responsibility of belonging on me. I couldn't blame other people for my not feeling like I didn't belong. That journey has just been so profound. This is what I see a lot of times with empathy is that we have these kinds of self-identities, but then we're afraid to open up and share. And we make these assumptions of other people, but, at the same time, there's real-world evidence. And so, how do we interpret that? In addition to this, Scott...like, part of the reason I called myself non-technical was because all of the people I saw who were like me or had my background, that's the word that was used to describe someone like me. And when I would go to a conference, you know, I have a feminine presentation. And this was ten years ago. My very first conference was 300 software developers, and there were probably about 295 men. And I was one of five women in the room. And because I looked so different and because I stood out, the first question that anybody would ask me, and this was about 30% to 40% of introductions, was, "Are you technical or non-technical?" And I had to choose between this binary. And I was like; I don't know. Am I technical? Like, is it a CEO that can code? I don't know. But then I have this background. And so I would just default to, "No, I guess I'm non-technical," because that's what felt safe because that's what they assumed. And I just didn't know, and I didn't realize that I was then building in this identity. And so then, as part of trying to create a warm and inclusive organization, we did one of the unconscious bias surveys from Harvard. And what astonished me when I did that myself was that I didn't have a whole lot of bias, like, there was some. But the most profound bias was against women in the workplace, and it stood out a big one. I was like, how is it that I can be someone who's a fierce advocate, but then that's my own bias against people like me? What the heck is going on? So really exploring all of this. And I think Scott and I have had so many different conversations over the years. We actually ended up getting married. And so we have a personal reason to figure a lot of this stuff out too. And when we start to have those conversations about who am I and what's important to me, then all of a sudden, we can start creating better code. We can start working together better as a team. We can start advocating for our needs. Other people know what we need ahead of time. And we're not operating out of defensiveness; we're operating out of collaboration and creativity. So the book and kind of everything is inspired by my background and my lived experience but then also seeing Scott and his struggles, too, because he had been told like, "You're a geek. Stay in the computers. Stay in the code. You're not allowed to talk to customers because you're bad at it," and flat out was told that. So how do we overcome these labels that people have put on us, and then we've made part of our own identity? And which ones are useful, and then which ones are not? Because sometimes labels can create a sense of community and affinity and so how do we know? And it's complicated, but the same thing, software is complicated. We can take skills like empathy and communication. We can look at them schematically and operationalize them when we look at them in kind of detail. So that's what I enjoy doing is looking under the hood and figuring out how does all this stuff work? So... [laughs] STEPHANIE: I did want to respond to a few things that I heard you say when you're talking about going to a conference and feeling very much in the minority. I went to my first RailsConf in 2022, my first RailsConf in person, and I was shocked at the gender imbalance. And I feel like every time I used the women's restroom; I was looking around and trying to make a connection with someone and have a bit of a kinship and be like, oh yes, you are here with me in this space. And then we would have a conversation and walk out together, and that felt very meaningful because the rest of the space, you know, I wasn't finding my people. And so I feel that very hard. I think this is also a good time to transition into the idea of makers and menders, especially because we have been talking about labels. So you all talked about this distinction between the different types of work in software development. So we have greenfield work, and that is writing code from scratch, making all the decisions about how to set up an application, exploring a whole new domain that hasn't been codified yet. And that is one type of work. But there's also mender-type work, which is working in existing applications, legacy code, refactoring, and dealing with the complexity of something that has stood the test of time but may or may not have gotten a lot of investment or care and bringing that codebase back to life if you will. And when I first heard about that distinction, I was like, yes, I'm a mender. This is what I like to do. But the more I thought about it, I started to also feel conflicted because I felt pain doing that work as well. ANDREA: Oh, interesting, yeah. STEPHANIE: Especially in the context of teams that I've been on when that work was not valued. And I was doing maintenance work and fixing bugs and either specifically being assigned to do that work or just doing it because I knew it needed to be done and no one else was doing it. And that had caused me a lot of frustration before because I would look around and be on a team with mostly White men and be like, why aren't they picking up any of this work as well? And so I was thinking about how I both felt very seen by the acknowledgment that this is work, and this is valid work, and it's important work, but also a little bit confused because I'm like, how did I get here? Did I pigeonhole myself into doing this work? Because the more I did it, the better I got at it, the more comfortable and, to whatever degree, enjoyed it. But at the same time, I'm not totally sure I was given the opportunity to do greenfield work earlier in my career. That could have changed where my interests lie. ANDREA: Yeah, it is. And it's funny that you mentioned this because I actually I'm a maker. But yeah, I created this community, and I'm known for this thing. And I had a very similar experience to how do I exist as someone who's different in this kind of community? And I think part of it is, you know, there's a great quote by George Box, who is a statistician, and he says, "All models are wrong; some are useful." And I think that's kind of the whole idea with the maker-mender is that it is a signal to be like, hey, if you like fixing stuff...because there is so much shame, like, that's what we were responding to. And Scott had the opposite problem of what you have experienced, where he was only allowed to work on greenfield work. They were like, "No, you're a good developer. So we want you working on features. We won't let you fix the bugs. We won't let you do the work that you like doing." And so that's why he wanted to create Corgibytes because he's like, "This work needs to be done." I am so personally passionate about this. And when we were having these conversations 13 years ago, I was talking to him about product/market fit and stuff like that. And I was like, "You like fixing software, and there's a lot of software out there to be fixed." I just was very, very confused as to why this kind of existed. And we had been told flat out, "You're never going to find anybody else like Scott. You're never going to be able to build a company around people who find a lot of joy in doing this work." And I think that this comes down to identity and kind of the way that Legacy Code Rocks was built too. A lot of the signaling that we put out there and the messaging and stuff really came from Scott's feeling of, like, I want to find more people like me. So being in the women's bathroom and like, how do I find more menders? Or how do I find people...because we were walking through a Barnes & Noble, and it was like a maker fest, maker everything. And he's like, "I don't have a community. There's nowhere for me to go to create these meaningful connections," exactly like you were saying. "I have maybe two people in my network." And then we were at a conference in 2015. We were at the large agile conference. And it was one of the first ones that I've been to that had a software craft track. And we met like 20 people who were really, like, I just saw Scott light up in a way that I hadn't seen him light up because he could geek out on this level that I hadn't seen him do before. And so when I asked, like, "How do you guys stay in touch afterwards?" And they're like, "Oh no, we don't. We don't know how to build a community." And it's like, well, okay, well, we can get that started. To your response of like, how do you operate when it is presented as a binary? And it's like, am I this, or am I this? This kind of gets down to the idea of identity-wise, is it a binary, or is it a spectrum? I tend to think of it kind of like an introvert-extrovert spectrum where it's like there is no wrong or right, and you can move in different places. And I think being able to explain the nuances of the modeling around how we came up with this messaging can get lost a lot of times. But I'm with you, like, how...and that's kind of something now where it's like, okay, maybe my role was to just start this conversation, but then everybody's having these ideas. But there are people who genuinely feel seen, you know. STEPHANIE: Yeah, that's really interesting because what I'm hearing is that when there's this dominant narrative of what a developer should be, and should be good at, and what they should do, it's kind of like what you were saying earlier about how hard it was for you to claim that identity yourself. People who feel differently aren't seen, and that's, I think, the problem. And I'm very, very interested in the gender aspect of it because one thing that I've noticed is that a lot of my female developer friends do do more of that mending work. So when you talk about feeling like there was no community out there, it just wasn't represented at the time, you know, a decade ago for sure. And still, even now, I think we're just starting to elevate those voices and that work. I wanted to share that at thoughtbot; we have different teams for different business verticals. And so we do have a rapid validation prototyping team. We do have a greenfield like MVP, V1 product team. And then we also have a team, Boost, the team that I'm on. That is more team augmentation, working with legacy code and existing systems. And it was not lost on me that Boost has the most women. [laughs] ANDREA: Yeah, because you have the concept of cognitive load and mental load. STEPHANIE: Yes. ANDREA: Women at home end up taking a lot more of this invisible labor that's behind the scenes. Like, you're picking the kids up from school, or you're doing the laundry, or all these things that are just behind the scenes. And this was actually something...so when Scott and I also got married, that's when I first became aware of this, and it was very similar. And it was, okay, how do I...because Scott and I, both in our business and in our personal partnership, we wanted it to be based on equity. And then also, like, how do I show up? And for me, the hardest thing with that was letting go of control where it's like, it has to be a certain way. It's hard for me to comment on the broader enterprise level because what I see at Corgibytes is we have gender parity. That's been pretty balanced over the course of our..., and we're a small boutique company, so it's different. But then, in the larger community of Legacy Code Rocks, it tends to be more male. There are actually fewer women in there. And I think, too, like there's this idea of testers and QA, like, I think that falls in there as well, and that's heavily dominant. And I think sometimes it's like, oh...and I think this kind of comes to the problem of it, like, it's the way that we think about the work in general. And this might be useful just to think about kind of the way that it came about was, you know, makers and menders was we were putting together [laughs] actually this talk for this conference that we went to. And my background in marketing, I was trying to wrap my brain around when is it appropriate for mending? And I had my marketing degree. It's like, oh, the product lifecycle. And Scott's retort was, "It needs to be a circle. We're agile, so it needs to be a circle." And I was like, this doesn't make any sense. Because look, if you have maturity and then you have it...oh my gosh, it'll link back to innovation, and then you can do new stuff. And so yeah, I think when we describe makers and menders, and this is true with any label, the idea in the broader model is that makers and menders aren't necessarily distinct, and your team should 1,000%...everyone should be contributing. And if you only have one person who's doing this work, you're at a detriment. That's not healthy for your codebase like; this should be baked in. And the mender is more of like, this is where I get my joy. It's more of an opt-in. But I think that your observation about the invisible labor and how that gets translated to maintenance work is accurate. A lot of times, like when Scott was describing his thing, it's like, there's the movie "Office Space." I might be dating myself. But there's this guy, Milton, and it's like, "Just go to the basement." He was told maintenance is where good software careers go to die. [laughs] And so over the years, it's like, how do we celebrate this and make it more part of the maker work? And it's similar to how introverts and extroverts...it's like, we all work together, and you need all of it. But there is an extrovert bias. And extroverts are seen more as, oh, they have leadership traits and stuff. But increasingly, we're starting to see, no, actually, that's not the only way that you can be effective. So I think it's hard. And I think it does come down to belonging. And I think that there are also different cultural impacts there. And it comes down to just a lot of different lived experiences. And I so appreciate you sharing your point of view. And I'm curious, what would help you feel more like you belong? Is it the work and the environment that you're in that's kind of contributing to this feeling? Or is it other things in general or? STEPHANIE: Okay, so I did want to address real quick what you were saying about mental load and household labor because I think I really only started thinking about this after I read a book called "Equal Partners" by Kate Mangino, where she talks about how to improve gender equality at home, and I loved that book so much. And I suddenly started to see it everywhere in life and obviously at work too. And that's kind of what really drove my thinking around this conversation, maintenance work being considered less skilled labor or things that get offloaded to someone else. I think that really frustrates me because I just don't believe that's true. And to get back to what you were asking about what would make me feel more seen or valued, I think it's systemic. But I also think that organizations can make change within their cultures around incentives especially. When you are only promoted if you do greenfield work and write thousands of lines of code, [laughs] that's what people will want to do. [laughs] And not even just promotions, but who gets a kudos in Slack? Or when do you get positive encouragement? As a consultant, I've worked on different client teams that had different values, and that was when I really struggled to be in those environments. I have a really strong memory of working on a greenfield project, but there was another male developer who was just cranking out features and doing all of this work and then demoing it to stakeholders. But then there was one feature that he had implemented but had faked the data. So he hadn't finished the backend part of it but just used fake data to demo the user interface to stakeholders. And then he moved on to something else. And I was like, wait; this isn't done. [laughs] But at that point, stakeholders thought it was done. They thought that it was complete. They gave him positive feedback for finishing it. And then I had to come in and be like, "This isn't done. Someone needs to work on this." And that person ended up being me. And that was really frustrating because I was doing that behind-the-scenes work, the under-the-hood work for something that had already been attributed to someone else. And yeah, I think about that a lot and what systems or what the environment was that led to that particular dynamic. MID-ROLL AD: Debugging errors can be a developer's worst nightmare...but it doesn't have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half. So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking! Airbrake's debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted. In addition to stellar error monitoring, Airbrake's lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction. Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality. Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back. Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today! STEPHANIE: Do you have any advice for leaders who want to make sure there's more equity for people who like to do mending and legacy code work? ANDREA: Yeah, absolutely. I am so grateful for your questions and your perspective because this is not something that's talked about a lot, and it is so important. I wrote an article for First Round Review. This was in 2016 or 2017. And it was called "Forget Technical Debt — Here's How to Build Technical Wealth," and so if you want to link to it in the show notes. It's a really long article and that goes into some of the specifics around it, but it's meant for CEOs. It really is meant for CEOs. And I do think that you're right; some of it is that we have lionized this culture of making and the work that is more visible. And it's like, oh, okay, great, here's all the visual design stuff. That's fantastic, but then recognizing there's a lot of stuff that's behind the scenes too. So in terms of leaders, I think some of it is you have to think about long-term thinking instead of just the short-term. Don't just chase the new shiny. Also, you need to be really aware of what your return on investment is. Because the developers that are working on maintaining and making sure that your mission-critical systems don't fail those are the ones that have the highest value in your organization because if that system goes down, your company makes money. Greenfield work, yes, it's very...and I'm not downplaying greenfield work for sure. I'm definitely, [laughs] like, I love doing that stuff. I love doing the generating phase. And at the same time, if we only look towards kind of more the future bias...there's a great book that we were featured in called "The Innovation Delusion" that talks about this more in general. But if we only look at the visible work that's coming, then we forget what's important now. And so for leaders, if you're running a software company, know where your mission-critical systems are and recognize the importance of maintaining them. That's the very first step. The second step is to recognize the complexities of a situation, like, to think about things in terms of complex systems instead of complicated systems. And I'll describe the difference. So when I came to software, I had been working in the creative field, like in advertising, and branding, and copywriting, and all that. And we got inputs. We kind of ran it through this process, and then we delivered. And we did a demo and all of that stuff. It was when is the timeline? When is it done? Big air quotes. And we were pretty predictably able to deliver on our delivery day. Sometimes things would go wrong, but we kind of had a sense because we had done the same pattern over and over again. You don't get that in legacy code because the variables are so immense that you cannot predict in the same way. You have to adopt a new strategy for how do you measure effectiveness. And the idea of measuring software productivity in terms of new features or lines of code, like, that's something that goes all the way back to Dykstra [laughs] in the 1970s around, is that the right way? Well, a lot of people who code are like, "No, that's not." This is a debate that goes back to the earliest days of computing. But I think that the companies that are able to build resilient systems have a competitive advantage. If a leader wants to look at their systems, whether that is a social system and the people in their organization or whether or not it's their software if you look at it from a systems thinking, like, there are interactions that I need to pay attention to not just process, that is super key as well. And then the last one is to recognize, like, one of our core values is communication is just as important as code. I would be remiss to neglect empathy and communication in part of this, but that really is so important. Because when we position things in terms of...and I don't know as much about thoughtbot and kind of the overall strategy, but kind of an anti-pattern I have seen just in general in organizational behavior is that when you structure teams functionally and silo them, you're not getting that diversity of thought. So the way that we approach it is, like, put a mender on a maker team because they're going to have a different perspective. And then, you can work together to get things out the door faster and value each other's perspectives and recognize strengths and shadows. So, for me, as a maker, I'm like, I've got a huge optimism bias, and we can go through all this stuff. And for Scott, it's like he struggles to know when he's done. Like, for me, I'm like, cool, we're 80% done. I got it. We're good to go. And for Scott, he'll work on something, and then it's like, I have to stop him. So recognizing that we help each other, that kind of thought diversity and experience diversity goes across so many different vectors, not just makers and menders. But I think, to me, it's about reframing value so that you're not just thinking about what it is right now in this moment. And I think a lot of this comes down to investor strategy too. Because if you've got an investor that you're trying to appease and they're just trying to make short-term monetary gains, it's much harder to think in terms of long term. And I think it's developers understanding business, business understanding the struggles of developers and how they need lots of focus time, and how estimating is really freaking hard, and why if you demand something, it's going to be probably not right. And then coming up with frameworks together where...how can I describe this in a way? So to me, it really is about empathy and communication at the end of the day when we're talking about interactions and how do we operationalize it. STEPHANIE: I like what you said about reframing value because I do believe that it starts from the top. When you value sustainability...my co-host, Joël, had an episode about sustainability as a value in software development. But then that changes, like I mentioned before, the incentive structures and who gets rewarded for what type of work. And I also think that it's not only diverse types of people who like doing different types of work, but there is value in doing both. And I know we talked about it being a spectrum earlier, but I strongly believe that doing the legacy code work and experiencing what it's like to try to change a system that you are like, I have no idea why this decision was made or like, why is the code like this? That will help inform you. If you do do greenfield work, those are really important skills, I think, to bring to that other type of work as well. Because then you're thinking about, okay, how can I make decisions that will help the developers down the line when I'm no longer on this project? ANDREA: Exactly, which is a form of empathy. [laughs] STEPHANIE: Yeah, it is a form of empathy, exactly. And the reverse is also true too. I was thinking about, okay, how can working in greenfield code help inform working with legacy code? And I was like, oh, you have so much energy when the world is completely open to you, and you can make whatever decisions to deliver value. And I've really struggled working in legacy code, feeling like I don't have any options and that I have to repeat a pattern that's already been set or that I'm just kind of stuck with what I've been given. But I think that there is some value in injecting more of that agency into working with legacy code as well. ANDREA: Well, and I think, too, I think you hit it on the head because, like I said, with the mental load at home, it was like, I had to be okay with things failing where it's like, it wasn't exactly the way I would do it, and I had to be okay with that. Like, oh, the dishes aren't put in the dishwasher exactly the same way I would do it. I'm not going behind it. And like, okay, it's not perfect. That's...whoo, it's going to be okay. And I think that's kind of what we experience, too, is this idea of we have to figure out how we work together in a way that is sustainable. And I think that, similar to my experience with the technical, non-technical piece, there is an onus. Now, granted, I want to be very careful here to not...there is trauma, and there is absolutely horrific discrimination and abuse. And that is not what I'm talking about here in terms of power dynamics. I am talking more about self-identity and self-expression. And I think that if you are in a community like makers and menders, yeah, we're less represented. There is a little bit of an onus, the technical, non-technical, like the onus of understanding what non-technical means and where I can push back is really important work for me to do. Because what I was surprised with was everyone there, like, when I started asking...so my response ended up being, "Help me understand, why did you ask that question?" And I took ownership of the narrative. And it was like, oh, well, what I found was that most of the people were like, if you're a recruiter, I don't want to waste your time with a bunch of stuff that you don't want to talk about. And then being able to say, "Oh, okay, I can see that, and you assumed that I was a recruiter because of the way I looked. And I understand the intention here. Next time, if I'm at a software conference, assume that I know how to code and assume that I'm here for a reason." And a great opening question is, "What brought you here?" I'm like, oh, okay, when we ask a close-ended question, we position things as a binary, like, are you technical or non-technical? That creates a lot of cognitive dissonance, and it's hard. But if I open it up and say, "What brought you here?" Then I can create my own narrative. There is an aspect of setting boundaries and pushing back a little bit like you said, agency. And that can be really hard because it gets at the core of who you are, and then you have to really explore it. And what I found, at least, is in the majority, there have been exceptions, but in the majority of the male-dominated groups that I've been in in my career in software, the majority are very welcoming and want me to be there. But I feel inadequate, and it's more impostor syndrome than I think it is people being discriminatory. Learning about the differences between that and where is my responsibility and where's your responsibility in this that's a tough tension to play. STEPHANIE: Absolutely. And I think that's why it's really important that we're having a conversation like this. I think what you're getting at is just the harm of the default assumption that is chronic, [laughs] at least for me sometimes. And you mentioned earlier the history of computing a little bit. And I was really excited about that because I did a little bit of digging and learned about women's history in computing and how after World War II, programming, you know, there were so many women. In fact, I think by 1960, more than one in four programmers were women, and they were working on mission-critical work like for NASA for, you know, during World War II for code-breaking. And I read that at the time, that work was deemed boring and tedious, and that's why men didn't want to do it. They wanted to work on hardware, which was what was the cool, creative, interesting work. And the computing work was just second class. That's changed, but in some ways, I'm thinking about, okay, where are we now? And to what degree are we kind of continuing this legacy? And how can we evolve or move beyond it? ANDREA: Yeah, you're absolutely right. And in some of the research for the book, one of the things I learned is a lot of people know the name, John von Neumann. He created the von Neumann architecture, that is the foundation of all the hardware that most of us use today. And the very first kind of general purpose digital computer, ENIAC, all...I think it was eight of the people who were programmers for that were women. That team was led by John von Neumann's wife, Klára, and you never hear about Klára. You have to go digging for that. And The Smithsonian actually just about 8, 10 years ago did a big anniversary and then realized none of those women were invited to the press conferences. They were not invited. And so there is kind of this...similar to generational wealth, it's the thing that gets passed down. Like, if you're in the rooms in the early days...there was a quote by John Backus, who created FORTRAN and the Backus–Naur principle, where he talked about programming in the 1950s. He has an essay, and he was like, yeah, I mean, an idea was anybody who claims it, and we never cited our sources. And so it was whoever had the biggest ego was the one who got credit. And everyone's like, great; you're a hero. And so I think that's kind of the beginning of it. And so if you weren't invited into the room, because in the 1950s, in addition to gender, there was legislation that prevented...we weren't even allowed to use the same bathrooms. You had White bathrooms and Black bathrooms. So you had very serious barriers for many different people getting into that room, and I think that gets to the idea of intersectionality as well. So the more barriers that you had, the harder it was going to be. And so then you get the stereotypes, and then you get the media who promotes the stereotypes. And so that is what happened to me. So I grew up in the '80s and '90s, and just every movie I watched, every TV show portrayed somebody who was, quote, "good" with computers in a very specific way. I didn't see myself in it. So I was like, oh, I'm not there. But then, when I talk to Scott, he's like, "Oh, I never saw that. I never saw the discrimination. I just saw this stuff." That's part of it is that if you were in that position where discrimination, or difficulties, or stereotypes had been invisible to you, the onus is on you to learn and to listen. If you are in a situation where you feel like you have been in the minority, the onus is on you to find ways to become more empowered. And a lot of times, that is setting boundaries. It's advocating for yourself. It's recognizing your self-worth. And those are all things that are really hard. And saying, hey, if we want to be sustainable, everyone needs to contribute. I'm happy to train everyone, but this is not going to work. And being able to frame it, too, in terms of value, like, why? Why is it a benefit for everyone building that empathy? And you're right, I mean, there are absolutely cultures where...who was it? I think it was Edward Deming. And he said, "A single person is powerless in the face of a bad system." And so if you're in a system that isn't going to work, recognizing that and can you move into a different system? Or can you change it from within? And those are all different questions that you've got to ask based on your own fortitude, your own interests, your own resources, your own situation. There is no easy question. But it's always work. And no matter who you are, it's always work. [laughs] STEPHANIE: Yeah, yeah. I joined as co-host of this podcast just a few months ago. And I had to do a lot of reflecting on what I wanted to get out of it and what my goals were. And that's why I'm really excited to have you on here and to be using this platform to talk about things that are important to me and things that I think more people should know about or think about. So before we wrap up, Andrea, do you have anything else you want to say? ANDREA: I want to reinforce that if you feel joy from mending, it's awesome. And there are communities like legacycode.rocks. We have MenderCon, and it's a celebration of software maintenance. So it can be really great. We have a virtual meetup every Wednesday. And there's a kind of a core group of people who come, and they're like, it's like therapy because there are a lot of people who are in your situation where it's like, I'm the only person on my team who cares about automated tests, and I have no idea like...and just having people who kind of share in that struggle can be really helpful, so finding your community. And then I think software maintenance is really, really critical and really important, and I think we see it. Like, we're seeing in the news every day in terms of these larger systems going down. Just recently, Southwest Airlines and all of these flights got canceled. The maintenance work is so, so valuable. If you feel like a mender and you feel like that fits your identity, just know that there is a lot of worth in the work that you are doing, an immense amount of worth in the work that you are doing, and to continue to advocate for that. If you are a maker, yes, there is absolutely worth in the work you're doing, but learn about menders. Learn how to work together. And if you are a leader of an organization, recognize that all of these different perspectives can work together. And, again, reframe the value. So I am so grateful that you framed the conversation this way. It's so important. I'm very, very grateful to hear from you and your point of view. And I hope that you continue to push the narrative like this because it's really important. STEPHANIE: Aww, thanks. And thank you so much for being on the podcast. ANDREA: Yeah, yeah, absolutely. Thanks for having me. STEPHANIE: Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeeeee!!!!! ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Richard talks with Andrea Goulet, a programmer at Corgibytes and coauthor of the book Empathy-Driven Software Development published by Pearson. They talk about the surprising interactions between technology and empathy, including how empathy for other programmers can lead to not only better interactions with other programmers, but even better understanding of the technology itself.

Robby has a chat with Andrea Goulet, the CEO of Corgibytes, a software development shop dedicated to maintaining and modernizing software applications. Named by LinkedIn as one of the top ten professionals in software under 35, Andrea is the host of the podcast Legacy Code Rocks, is the author of the forthcoming book, “Empathy-Driven Software Development”, has co-founded several successful technology companies, and has taught over 50,000 students how to turn soft skills like empathy and communication into software skills.Through her newest venture, Heartware.dev, she is on a mission to operationalize empathy for tech teams and keynotes frequently about building a business based on balance, empathy, and trust; the perils of the technical/non-technical divide; and the technical philosophies around working with legacy code. Andrea says that the maintainability of software comes down to trust and while she doesn't find the term technical debt useful, she uses it in instances where it's being widely used especially in software remodeling projects. From her experience, the term is not useful at all when dealing with business-minded people who view debt differently.She points out that the success of a project is always highly dependent on the project owner and the team working on their project having shared goals as they approach the writing of software. Robby and Andrea will also dive into why we should avoid deferring to other people and defaulting to being ticket takers, how empathy has different definitions, avoiding us vs them thinking, and so much more. Stay tuned and enjoy!Book Recommendations:Set Boundaries, Find Peace: A Guide to Reclaiming Yourself by Nedra Glover TawwabHelpful Linkshttps://twitter.com/andreagoulethttps://heartware.devhttps://corgibytes.comComing in 2023! Empathy-Driven Software Development by Andrea GouletSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.Join the discussion in the Maintainable Discord Community

Empathy is software skill. It might sound strange, but after my conversation with Andrea Goulet I strongly believe that's the case. She explains how trust is the foundation of not only great software, but also great engineering teams. How do we build trust? Through empathy, and Andrea lays out some great practical examples of how it benefits everyone. More of the topics we cover this episode, in order

A portal outage won't stop Andrea Goulet and Naomi Ceder from coming into the café for coffee and conversation. Listen in as they discuss empathy in open source software development.

Watch this episode to learn why empathy involves a suite of technical skills. Andrea Goulet is the author of Empathy-Driven Software Development. In this episode, she describes why the industry needs more empathy. Not only to help it overcome a history and culture of shame and contempt, but also to help its coders flourish by developing 12 empathy skills. 00:00 – Introduction 00:25 – About Andrea Goulet 1:04 – Why empathy matters to software development 2:42 – Deconstructing what empathy means for software engineers 3:49 – The role of empathy in technology 6:00 – Why is there a culture of contempt and shame in the software industry? 10:27 – What is an Empathy System Architecture? 12:31 – How can empathy create a resilient software system? 14:21 – What programming and empathy have in common 18:23 – Why the software industry needs a systems overhaul to overcome a culture of contempt 23:20 – How to create a culture of empathy in tech 29:04 – Andrea Goulet's Purposeful Empathy Story 34:27 – Conclusion CONNECT WITH ANDREA ✩ Twitter: @andreagoulet ✩ LinkedIn: https://www.linkedin.com/in/andreamgoulet/ ✩ Business: www.heartware.dev ; corgibytes.com ✩ Online community: empathyintech.com CONNECT WITH ANITA ✩ Email purposefulempathy@gmail.com ✩ Website https://www.anitanowak.com/ ✩ LinkedIn www.linkedin.com/in/anitanowak ✩ Instagram https://tinyurl.com/anitanowakinstagram ✩ Twitter https://twitter.com/anitanowak21 ✩ Facebook Page https://tinyurl.com/PurposefulEmpathyFacebook ✩ Facebook Group https://tinyurl.com/PurposefulEmpathyCommunity ✩ Podcast Audio https://tinyurl.com/PurposefulEmpathyPodcast This episode was brought to you by Grand Heron International REACH THEM AT ✩ Website www.grandheroninternational.ca; www.ghi.coach ✩ LinkedIn https://www.linkedin.com/company/grand-heron-international/ ✩ Facebook https://www.facebook.com/grandheroninternational/ ✩ Instagram @Grand_Heron_International ✩ Twitter @GrandHeronIntl ✩ https://twitter.com/GrandHeronIntl To watch the video with subtitles: https://www.youtube.com/channel/UC78vaeHVmoxebZCYtqsKe0A Video Edited by David Tsvariani

In this episode, we host Andrea Goulet, and she brings her own heuristic: “Empathy system architecture”. She has been doing research about empathy within the software industry, and the results are amazing. We discuss the implications of empathy both at the individual level, as well as, group level. Last but not the least, we discuss one of her passions, legacy systems and the hidden communication artifacts with it! Andrea recommends: Practical Empathy, For Collaboration and Creativity in Your Work by Indi Young    The War For Kindness, Building Empathy In A Fractured World by Jamil Zaki Living Documentation: Continuous Knowledge Sharing by Design by Cyrille Martraire Andrea Goulet (@andreagoulet) 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 and learn more about her work at https://empathyintech.com.

Rob interviews Andrea Goulet, Co-Founder of Corgibytes, and a prominent thought leader in the technology industry.Get answers to big questions like, - Is there a change afoot in software that makes empathy more relevant now? Or is talking about empathy long overdue in our industry?- Can empathy be learned? - What long-term impacts can developers make by building more empathy into their practice?Tune in today and if there's something you want us to hear discussed on a future episode, reach out to us on twitter at @circleci!

In this episode, our Co-Hosts, Julia Barnhart and Ford Prior, sat down with three technologists in the Richmond area to discuss the current trends in technology. This panel includes Andrea Goulet, Scott Ford, and Greg Patrick. 

The first step to mastering any skill is demystifying it. However, this is not easy to achieve on your own, and often masters of the craft around you are not as helpful as you would hope. It is easy to forget how it is to be a novice once we achieve expertise in some field, and this leads many of us to lose the ability to introduce the craft to the incoming forces patiently and in simple terms.  Today we talk with Sharon DeCaro. Sharon has been working as a software engineer for five years. However, this wasn't her career choice when she enrolled in the mathematics and music program at her university. Listen to Sharon as she tells us about her journey into the software industry, the hurdles she encountered, and the ways she overcame them to become a software engineer.  When you finish listening to this episode, make sure to connect with Sharon on LinkedIn. Mentioned in this episode: Sharon on LinkedIn at https://www.linkedin.com/in/sjdecaro/ Andrea Goulet, Carmen Shirkey Collins, Empathy Driven Software Development at https://www.empathyintech.com 

Today, we're talking to my friend, Andrea Goulet.  Andrea is an author, an empathy driven software developer, and an ADHD mom. In this episode, Andrea discusses the patterns of emotions and communication.  She talks about the value of recognizing what we say about ourselves, the limits of binary thinking, paying attention to messaging, and the importance of empathy. >>> ADHD Essentials Parenting Groups

01:00 - Mae's Superpower: Being Able to Relate to Other People and Finding Ways to Support Them 03:42 - Contributing to Humanity (Specifically American Culture) * Title Track Michigan (https://titletrackmichigan.org/) * Climate Change * Clean, Accessible Water * Hate & Divisiveness; Understanding Racial Justice 07:01 - Somatics (https://en.wikipedia.org/wiki/Somatics) and The Effects of Yoga, Meditation, and Self-Awareness * Flow (https://en.wikipedia.org/wiki/Flow_(psychology)) * Kripalu (https://kripalu.org/?) * PubMed (https://pubmed.ncbi.nlm.nih.gov/) * Cognitive Behavioral Therapy (CBT) (https://www.apa.org/ptsd-guideline/patients-and-families/cognitive-behavioral) * Debugging Your Brain by Casey Watts (https://www.debuggingyourbrain.com/) 12:20 - Mutual Aid: Solidarity, Not Charity * WeCamp (https://weca.mp/) * Ruby For Good (https://rubyforgood.org/) * Harm Reduction * Encampments * “We keep us safe.” * Rainbow Gatherings (https://en.wikipedia.org/wiki/Rainbow_Gathering) * Burning Man (https://burningman.org/) * Big Big Table Community Cafe (https://www.bigbigtable.org/) 33:17 - Giving vs Accepting Help; Extending and Accepting Love, Empathy, and Forgiveness * Collective Liberation * The Parable of Polygons (https://en.wikipedia.org/wiki/Parable_of_the_Polygons) * Listening: What could be of use? * 99 Bottles of OOP (https://sandimetz.com/99bottles) – Sandi Metz (https://twitter.com/sandimetz) 48:25 - The Mental Health Challenges of Being a Programmer * Celebrating Small Wins; “Microjoys!” Reflections: Casey: The word mutual aid can be more approachable if you think about it like people helping people and not a formal organization. Also: help and be helped! Jamey: Valuing yourself and the way that helps the communities you are a part of. Mae: Engaging with users using the things your building is a reward and a way to give yourself “microjoy!” This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.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 (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: JAMEY: Hello and welcome to Episode 238 of Greater Than Code. I am your host, Jamey Hampton, and I'm here with my friend, Casey Watts. CASEY: Hi, I'm Casey, and we're both here today with our guest, Mae Beale. Mae spent 20 years in and out of nonprofit-land, with jaunts into biochemistry and women's studies degreeing, full-time pool playing, high school chemistry and physics teaching, higher ed senior administrating, and more. She went to code school in 2014 (at 37 years old) to gain the technical skills needed to build the tools she wished she'd had in all the years prior. So glad to have you, Mae. MAE: Thanks, Casey. Thanks, Jamey. Same for me. JAMEY: So you may be ready for the first question that we're going to ask you, which is, what is your superpower and how did you acquire it? MAE: Yeah, thank you. I think that my superpower is being able to relate to other people and find ways to support them. How did I get good at that? Well, I've dealt with a lot of pretty complicated people in my life that you have to do extra thinking to figure out. So I think I got my start with that and I've done lots of different things in life and met lots of different people and felt lots of different feelings and thought lots of different thoughts. So I think that's mostly it: living. JAMEY: I was going to say that I know from knowing you that you've done lots of things, but even our listeners who don't know you probably already know that just after listening to your bio, so. [laughter] MAE: Yeah, and there's plenty more that didn't make it in there. That's something that is fun and a joke is no matter how long people know me, there's always still something that they didn't know and so, that's fun for me. I like to surprise other people and I love being surprised by people. So it's like a little game I have with all my fun facts. JAMEY: I love that. CASEY: I've got a question: what's on your mind lately. MAE: What is on my mind lately? So many things, I don't even know where to start. One is where and how can I contribute to the future of humanity [chuckles] and American culture in particular and in the circles that I'm in, drawing it down even more. So I think about that a lot. I think about my house a lot. I just bought a house and I'm going to do each room with a color theme so it'll end up being, you walked through the rainbow. Pretty excited for that, lots of things there. And I think a lot about how to empower others and be a more and more effective communicator. I think about that a lot. Probably those are the top ones and maybe Dominion. I play that every day. So I think about that a little bit. CASEY: [chuckles] Love that game. JAMEY: Me too. CASEY: This is great. All three are really interesting. I want to start on your first one. What opportunities do you see lately, or what have you done recently, or what do you hope to do to help the world help American culture help make an impact? What are you working on? MAE: From where I sit, it seems like the most important things that any of us can attune to about even a portion of is the environment and whatever's going on with our ability as humans to respond to climate change and water, like clean, accessible water for people, and hate and divisiveness. Those three things I think are our biggest challenges. So I try to do things that end up in those spheres, if not in things that ideally have some mix of those rather than having them be silos. One of my jobs is working with Title Track Michigan, and they are a relatively new nonprofit that brings creative practice to complex problems and is specifically focused on water protection, racial equity, and youth empowerment. Once all the uprising started in 2020, we created an Understanding Racial Justice course for white people in Northern Michigan and so, I've been helping to facilitate those courses and taking as many opportunities to rethink my orientation to all those topics as well. CASEY: That's so cool. You found a group that does all of those things in one. MAE: Amazing, right? CASEY: Wow. Title Track Michigan, huh? MAE: Yeah. I found them because my life radically changed a few years ago. A lot of things changed at once like, not just a lot, all of the things. So I went on this walkabout just trying to find ways to be of service in the world without expectation, watch who I met, and where I ended up. I ended up in Michigan and getting introduced to these people who then were creating a new nonprofit Title Track. Another thing I do is I have a consultancy that I have a flagship enterprise product for nonprofit, small business administration. That is a little bit of a Trojan horse for change management and organizational development and sustainable longevity planning for organizations. So the fact that I ended up there with them at that time and way more cool synchronicities happened. That's how I met them. So it just feels right and great to have landed in that space and then to have 2020 be what it became, we were already formed and positioned to try to be of help. JAMEY: This is an abstract question. MAE: Okay. JAMEY: But what does it feel like to feel like you're doing the right thing in that way like, the right place to be? I got the sense from you telling this story that things just came together in the right way at the right time and that's a beautiful thing when it happens and you said it feels right. What does that feel like? MAE: Mm thanks, Jamey. Well, my first thought is another thing that Title Track does in that Understanding Racial Justice course and a lot of circles I've ended up in have a focus on somatic and so, body centered awareness and engagement. So I used to always think my answer was going to be emotional when people ask me, “How do I feel?” and now I hear and think of my body first so that's cool. I'll answer a couple of ways, if that's okay. When for me synchronicities happen and I feel most alive, or of use, which is important to me, my heart literally feels bigger and almost breathing like I can feel air. I don't know how to explain that. I definitely will be smiling more, my back is straighter, and I usually have a lot more to say. All of a sudden, I'll have a lot to say. Other times, I have nothing to say! For how I might've answered that question previously would be closer to having a lot of things to say, like I'm a lot more creative, making connections, getting excited, and wanting to create new things together with other people. How about you two? CASEY: Just hearing you describe that, I have thought back on times I felt really proud and engaged and I noticed my posture improved, too. That's so interesting. I've had a nerve injury for 2 years. My hands go tingly sometimes. So I'm working on my back and noticing posture all the time. Interesting how my mood like that could affect the posture. I believe it, too. JAMEY: I'm not sure that I would have called out posture specifically in that way, but now that I'm thinking about it, I think what I would say is I feel lighter. MAE: Yeah! JAMEY: So to feel less bogged down, I can see in what way that's related to posture. [chuckles] MAE: Totally. Yeah. CASEY: We all have a lot to say on this, I love it. [chuckles] This reminds me of the Flow State. So when your skills match a need and it's challenging the appropriate amount, you're in a great concentration state, but if your skills aren't enough, or if the need isn't important enough—either one—feels a little way less good, not good. JAMEY: Totally. MAE: I lived at a yoga retreat center for a little while in Massachusetts called Kripalu—it's the largest yoga retreat center in North America. I had never done yoga and I was like, “Oh, cool. I'll just go live there [laughs] and see.” Anyway, I was there for three months and they have a part of their organization dedicated to optimal human performance. They have a partnership with Tanglewood and some other places around there to see if yoga and meditation can induce more Flow State, more of the time for top performing musicians, and just to be able to have more “scientific evidence” about how physiologically we can do things to get ourselves closer to those states more often. Pretty cool work. JAMEY: Yeah. That's really interesting. CASEY: I was just doing some research on the effects of different types of yoga and meditation on anxiety. I was trying to read some of the primary sources. I like to go to PubMed first—that's my go-to. Some people do Google Scholar. It's interesting, the framing sounded in a couple of papers like, “Well, it's not as good as CBT,” and my takeaway was, “Well, it helps an amount, huh? Great, good.” [laughter] So people who can't get access to CBT should consider that and that's true anyway. Science has shown this thing we knew was helpful anyway, is helpful in an empirical sense and that's great. MAE: Totally. Casey, for anybody who might not know what CBT is, would you be willing to…? CASEY: Thank you. CBT here is Cognitive Behavioral Therapy, which is one of the most common and effective forms of talk therapy you would do with a therapist. It focuses on what some maladaptive, unhelpful thought patterns are and helps you change them. MAE: And that's coming from a psych major, right, Casey? CASEY: That's right. I talk all about that in my book, Debugging Your Brain. It's funny, but you're flipping the script here. Usually we do this to our guests. MAE: [laughter] Great! CASEY: Love it. JAMEY: There's another project, Mae that I know that you've worked on that. I'm a little bit surprised that you haven't brought up yet, but I'm going to bring it up, which is your Mutual Aid program. MAE: Thank you. JAMEY: I think that when you are talking about doing something to make an impact on the world, like that was the first thing I thought of since I know you're involved with that and I would love to hear you talk about it. MAE: Yes. Thank you. Thanks for bringing that up and I did want to talk about that and I was looking forward to hearing what you have to say about that topic as well. So when the pandemic started, you may have seen these, or become involved, but there was a whole bunch of spreadsheets starting like Google Sheets of people who had some needs and people who wanted to offer some things. Google spreadsheets are really easy first pass for people with low tech skills and no budget to just come together. But I started being invited to all these different spreadsheets from around the country that include people's name, address, phone number, CashApp name, their exact vulnerabilities and identities, and current struggles in a spreadsheet that's downloadable. It really freaked me out and I started coding that day about how can we start to do something to make these people not have to have their identity so exposed and through like WeCamp networks, Ruby for Good networks, and different Slacks I'm in of varying programmers, I started saying, “Does anybody else want to get involved?” and several people did. So we have built a platform to support mutual aid groups and what we did immediately was find some groups to figure out what their needs were instead of just what we might imagine. They were doing a lot of, we call it dispatch moderated setups where people fill out a form and then volunteers read the forms and then match people and do all the communication manually, but not having peer-to-peer things go on. The system was originally designed to support that dispatch moderated set up and once people started to go back to work in the fall and there weren't as many people able to devote as much time to volunteer, and as varying groups, especially ones that hadn't been around as long, realized they would probably need a lot more training in social work, ask things just to be more effective and figure out how to route people correctly within their community to services that might be able to help them a little more. Since the fall, we've to coding peer-to-peer solution. We have several different mutual aid groups around the country and right now, most closely working with groups in Michigan and New York state, just because that's where our networks are. Getting to launch some peer-to-peer stuff, but mutual aid itself has become a buzzword and like, what is that anyway? [chuckles] So that topic I love talking about. There's like a mutual aid saying, “Solidarity, not charity.” The whole thing is we're all in it together and we're not going to rely on different structures, or institutions that were set up most often in ways that institutionalized various forms of oppression. Just empowering people to connect with each other, have stronger networks, and build more resiliency is what's up with it, but mutual aid has been around for over a 100 years, at least as a term and a thing, but it generally, almost always springs from communities that have been disenfranchised. So when the pandemic started and a lot of new groups formed, not everybody had already checked what's already happening and a lot of different people, especially in communities of color, were surprised by like, they didn't hear that term, that's just what they do. There's been a big—along with everything else—learning of how those structures already were in place and how we can continue to grow them, and support each other as we navigate this world we're in. Jamey, I was going to ask you about your involvement with mutual aid, too and if you had anything to add to that definition. JAMEY: I was going to say that I really liked what you said about finding new ways around things that have been institutionalized. Because I think one of the things that's so beautiful about mutual aid is the way that people can help each other realize what kind of help is available and what kind of help they even might need. A story that I really like to tell that and I think about a lot is I have a friend who's involved in mutual aid in Buffalo, where I'm from and he does repair work and just is very handy in that way. So he does a lot of mutual aid repair for people and he told me that the way that this started for him is that there was a request in our mutual aid Facebook group where someone was saying, “I really need $200, or something like this because my window is broken and I need to buy a space heater because it's been getting really cold. So I need this money to buy a heater and all of this stuff.” My friend came in and was like, “Okay, but what if I just fixed your window?” It had not occurred to this person that she could ask for that. MAE: Oh, boy. JAMEY: She was coming up with all these solutions around it. So this idea of like coming together as a community and saying, ‘Yeah, I can help you, but can we help a little bit closer to the source than what you even just asked for?” I think is really powerful. MAE: Yes. I love that, Jamey. Yeah, it's the closer we can be in community with each other, the easier those asks are. Something that you said about figuring out your own needs, there is a thing and it's related a little bit to some of the other topics we've talked about where there's like the white savior thing. People want to do something for people who they think are less – they have less than them. There's a power dynamic there and mutual aid—mutual, that's the main part. So you really aren't doing mutual aid if you're not accepting help. All of us have things that we could be supportive with and things to offer. I love also having that not – there's a lot of mutual aid that is about just giving money and/or like reparation stuff. But I love when money isn't part of the equation and quantification of value isn't part of the equation. It's just like, “I have something to give and I could use something and this is how we're going to stay in community and in network and lower those barriers to have offers and asks be even easier in the future.” JAMEY: For sure. I think it's about meeting people where they are, too, because I agree about some programs are focused on money, and some people have money and can put that into the community and that's great. But maybe they don't have time to show up and do these things and other people might think like, “Well, how can I help because I don't have money,” but they have time, or they have skills. I think that everyone bringing in and saying, “This is what I have to offer with what's going on in my life right now,” and maybe it's money, or maybe it's time, or maybe it's something else that I didn't even think of that they're going to offer. [chuckles] MAE: Totally. When you were saying that, I just got a chill thinking if really every single person just that question you just said, “How can I help?” If we all did one thing, this is how to effect broad change. CASEY: How can people find the mutual aid groups near them? If they just search mutual aid, that probably gets a bunch, but they don't all say it, right? MAE: Yeah. It's a really great point. There have been some different efforts to link together mutual aid networks and there's a map, but not every network is on it because not every network even knows about it. [chuckles] So because mutual aid is so grassroots, it's not – CASEY: Right. MAE: A number of them have form 501(c)(3) is just to not be doing illegal financial transaction stuff that is problematic by having all this money go through their personal Venmo, or something. But that is what a lot of people have done. So mostly there's the Google option and the term mutual aid is getting used more and more, but there are some other phrases. I'm forgetting it right now. What's the name when they hand out medical supplies? Harm reduction, there's a bunch of harm reduction efforts. Also, in cities where there are a lot of homeless shelters, there's things around encampments and like becoming community with those folks to advocate. Another piece, major piece of mutual aid that I forgot to name is it inherently has a political engagement component in it. So one of the reasons why it is this solidarity thing is you're seeing all the humans as inherently equally valuable and that you're identifying the structural things that led to people having a different experience, or a different privilege, or a different outcome to what's going down for them. So then by identifying those together, you try to change the system to not create the problem. Whereas, to go back to that phrase charity, a lot of charities—which are awesome, I'm not trying to knock those—but a lot of them have more of a it's your fault, or shortcoming, or need that has put you where you are. Mutual aid is the way in which this is all rigged and on purpose, or not on purpose, or just the impact of the structures is how you ended up where you are so let's rejigger. JAMEY: A phrase that comes up a lot, in the protest community specifically, is, “We keep us safe and we say that at protests about security, medics and things, and wearing masks—I've seen people start to use that phrase. But I think that that's a phrase that really speaks to like what mutual aid is about, too. It's about we are doing something together for ourselves as a community, and we're not looking for something from the outside that comes in a hierarchical structure. We're just making this decision as a group of people to take care of ourselves and our neighbors and I think that's what I really love about it. [chuckles] MAE: Totally. Yeah, absolutely. And back to what you were saying, Casey, the how can people find those things? There's also just, “Hey, I've got some extra seeds,” or put a cabinet in your yard with some food in it and say free food. You don't have to associate with a “mutual aid group” to do mutual aid. It's like, that's just a blanket term, basically that offers a little bit of a cue about what those people might be up to. But it's really, in whatever way you are sharing and developing relationships with your fellow community members. This is mutual aid. JAMEY: I thought of another example of that. MAE: Yay! JAMEY: We have this in Buffalo, but I think it's a thing that we're seeing other places, too. Separate from our mutual aid network, we have a Facebook Buy Nothing group. MAE: yes. JAMEY: And people will post like, “Oh, I have this, I'm going to get rid of it. Someone come pick it up.” “Oh, I was going to donate these spoons from my kitchen. Someone can have them.” When you said seeds, that's the kind of thing you'll see on Buy Nothing and I think that's been a revolution in anything even separately from it, because I do think that money plays a part in a lot of mutual aid stuff, because folks need money for things. But in Buy Nothing, it's pointedly without money and I think that that's a very fun and cool dynamic, too. MAE: Totally. Yes. I have a couple of things I would love to say them. One is that the bringing up Facebook has started to support mutual aid. But also, I don't know if y'all have seen The Social Dilemma and just become aware of all of this tracking that's going down. There's something that is another motivator for us on the mutual aid repo is this is open source code that anybody who wants to use it can stand up their own instance and if you partner with us, connect with us, we will help you if you need us to. But it's intentionally not a multitenant app so that people have small datasets that they own and there isn't like this aggregate thing going on about local data. It's basically a small tech for the win, which is also pretty mutual aid-y. Our group, like the programmers who are most involved, meet a couple times a week and know about what's going on in each other's lives. We are mutual aid for each other, too. The energy of what, how, who we are, and what we're doing is getting put into the thing that we're building that hopefully has that same effect. So there's this nice spiral thing going on in there that I'm proud of. I think there's a lot about what we referenced earlier, institutionalization of oppression, that has to be like, there are ways to create other options and they take cultivation of and building new structures. Stuff like this as an example of that and an experiment in it. Another one that it reminded me of is when I was younger, I used to go to rainbow gatherings. I don't know if y'all know about these. It's a super hippie thing and there's regional gatherings, but there's a national gathering at a national forest every year. All these people just show up and then they build earthen stoves. There's a bunch of people who do not participate in main society; they just go to these different gatherings and travel around as a… There's plenty more to talk about rainbow tribe and even the usage of that word tribe and what goes down. I'm not going to try to touch into that, but something I love about it is there's a whole exchange row where people just sit out with things and there's no money. You're not allowed to use money. I think I was 18 when I went to my first one and I was just like, “What? This is amazing.” Like, just to imagine my life not through a currency, or that evaluated exchange, it was so inspiring to me. It still is and so, some of what you said, Jamey, reminded me of that. JAMEY: I relate a lot to that, too. Burning Man events are also no money allowed. MAE: Ah. JAMEY: When I first entered that space, that was one of the things that really spoke to me about it too. In fact, it's also no barter allowed in Burning Man. It's a purely gifting economy where if you give someone something, a lot of times they become inspired to gift you something back right there and there's an exchange that happens. But culturally, the point of it is that there's not supposed to be any expectation of exchange when you gift something to somebody. MAE: Do you know about that restaurant in San Francisco that is free, but you pay for the person behind you if you want? JAMEY: I don't know about one in San Francisco specifically, but we have a program like that similar in Buffalo. It's called Big – I'm going to look it up so I can link it up. MAE: How about you, Casey? I'm getting excited so I keep saying things. CASEY: I'm reflecting on the award mutual aid a lot through all this. I like this idea that mutual aid as it is in action and that mutual aid groups do mutual aid, but individuals can, too. MAE: Yeah. CASEY: That's a pretty powerful theme. It makes the term more approachable, especially since it's a jargon word lately. It's just grassroots-y helping each other out, however that looks. MAE: Totally. CASEY: I'm thinking a lot about what communities I'm a part of, too, that naturally have that phenomenon. It's like, I'm queer, I'm in a lot of queer groups. I'm in interest groups like musician groups and they help each other do stuff. They carpool to the practice or anything like that that's this. There's also a formal ones like D.C. Ward 6 has mutual aid groups that are named that. That's its own thing. And then even my Facebook friends, I just post like, “I have a crackpot, who wants it?” MAE: Totally! CASEY: But before today, I might not have used the word mutual aid to describe any of that because I'm not part of a formal approved mutual aid group, which is not the point of that term. MAE: [laughs] Yeah. CASEY: Just people helping people. MAE: When I was thinking about getting into tech, I, as a pretty outspoken woman who will address injustice directly if I see it, when I see it in myself and others, I wasn't sure if that was going to be a place for me. I had had some not awesome experiences with tech people before I was in tech. So I reached out to a bunch of people who were already in the biz and they spent hours talking to me about their experiences, answering all of my questions, and offering to help me. As I took the leap and went to code school and participated in a meetups and just, everywhere is mutual aid in programming, everybody is helping each other. “I have a question,” “I'm wondering about this.” This podcast is mutual aid, in my opinion. It's been really inspiring for me to be a programmer because I feel a part of a worldwide network of people who try to, especially with mixing in the open source piece, build things and offer what they can. It's awesome. CASEY: I have a challenge for people listening to this podcast. This week, I'd like you to help someone and accept help from someone, both in the spirit of mutual aid. MAE: Yes! CASEY: I'm not surprised; accepting help might be the harder half for a lot of people. MAE: Yes. JAMEY: I think that's true. [chuckles] MAE: One way I've said it before is that that is your gift to the giver. The giver doesn't get to be a giver [chuckles] unless you accept the gift from them and that people can, including myself at times, tend to over-give and that is its own challenge. So if you need to stay in the giving frame, [chuckles] you can be like, “All right, well, I'm providing this opportunity to the other person.” [chuckles] CASEY: Sometimes I've playfully pushed on an idea to people. I'm trying to help them and they say, “No, no, no. I can't accept your help because I would be indebted,” and I'm like, “You would deprive me of this good feeling I would get from helping you? Really?” [laughter] MAE: Yeah. CASEY: Thinking of it a little bit, I'm not like – [overtalk] JAMEY: [inaudible]. CASEY: Right. I'm just thinking that way a little bit, flipping it, helps some people accept the help then. MAE: Yeah. JAMEY: I think that people have so much harder of a time of extending love and empathy, and forgiveness, and all of these nice things that we might really value extending to other people, but not to ourselves. MAE: Yo, that's for real, Jamey and still on this theme, the seeing each other as equals as in community. My Mom used to say this great phrase, “There but for the grace of God, go I.” She was raised Catholic so it's got that in there, but I love that of this could definitely be me. There's a cool Buddhist practice that I learned from Pema Chödrön about you extend release of suffering to others and then you widen the circle to include yourself in it, but you don't start there. So similar to how you're saying, Jamey, that that is a challenge for a lot of people, it's just built into that practice where when you can't give yourself a break, [chuckles] imagining others in that situation and then trying to include yourself is an angle on it. JAMEY: I like that. I think also related to Casey's example of his joke. It's thinking about how what you do affects other people, I think sometimes we're better at that and if you're treating yourself bad, especially if you're in one of these tight mutual communities. If you're treating yourself bad, that's affecting the people around you, too. They don't want to see you being treated bad and they don't want to see you being miserable and they want the best for you. When you're preventing yourself from having the best, that's affecting the whole community, too. MAE: Yo! JAMEY: I hadn't really thought about it like that until right now. So thank you, Casey, for your joke. CASEY: Powerful thought. Yeah. Like the group, your people, your team, they need you to be your best. So if you want to help your team, sometimes the best way is to help yourself. It's not selfish. It's the opposite of selfish. MAE: Exactly. Another thing I've heard a bunch of the different activist groups, some phrasing that people have started to use is collective liberation and no one's free till we're all free and if we are suffering, the other people are suffering and vice versa. So figuring out how to not be so cut off from ourselves, or others, or that suffering and seeing them as intertwined, I think is one of the ways to unlock the lack of empathy that a lot of people experience. CASEY: There's a really cool visualization I like that that reminds me of. It's called the Parable of the Polygons and you can drag around triangles and squares. You can see how segregation ends up happening, if you have certain criteria set up in the heuristics of how they move. Or if some people want to be around diverse people, it ends up not happening, or it ends up recovering and getting more integrated and mixed. It's so powerful because you can manipulate the diagrams. There's a whole series of diagrams. Look it up, it's the Parable of the Polygons. MAE: Cool! That is awesome. CASEY: So I want to be around people who aren't like me and that helps. It helps with this phenomenon and the more people do that, the better. MAE: Yeah, and having grown up in a small city, that's pretty homogenous on multiple levels. When I went to college and learned that people thought differently, my world was this very rigidly defined, this is how things are. [chuckles] My biker dad, that's still his way, his lens. When you start to experience people who are not like yourself, you let that challenge your assumptions, then you end up transformed by that. I was a double major in college—biochemistry and women's studies—and I remember being in an organic chemistry class and the professor said, “Well, if that's too hard for you, you can go take a sociology class.” I raised my hand and was like, “My sociology classes challenge me on every single thing I think about the world. Your class requires me to provide rote memorization, which I'm awesome at luckily and that's how I ended up in your class.” But that is not harder. That's that story. CASEY: The last episode that I recorded was with Andrea Goulet. One of the things that kept coming up was the old-timey programming interview questions were all about math. MAE: Yes. CASEY: Which isn't necessarily what programming is about. That reminds me here of rote memorization in that class versus complex systems thinking in sociology. MAE: Totally!
 CASEY: With these two choices, I might choose a sociology person to do architecture work in my software than the rote memorization person. MAE: Totally, definitely, every time. Yeah, and that's a different lens that I have coming in to the industry from having been an administrator for so many years is our perception as programmers about what's going to be helpful is very different than someone whose day job is to do repetitive work like very, very, very simple apps. When I was in code school, I really wanted us to figure out how to make even our homework assignments be available for nonprofits and that's how my whole system in business ended up getting spun up. Oh, it was before that. My job before that, when I interviewed, I said, “Well, how long do you need someone here for? How long would you need me to commit?” and he said, “A year,” and I said, “All right, well, I'm not sure I'm the best candidate for you because I'm going to go to grad school and get a degree and be a consultant as businesses and nonprofits.” And then I was at that job for 8 and a half years before I went to code school. [laughs] But the thing about what could be of use just requires so much humility from programmers to defer to the actual employees and the workers about their experience and what could help them. Because so often, we think that we're the ones with the awesome idea and we can just change their lives and disrupt the thing. A lot of the best ideas come from the people themselves. I went to a project management training in Puerto Rico and it was a very rarefied environment of people who could pay for people to get PMP training, or whatever. The people that were in my cohort were factory project planners and not a single one of them knew anyone who worked in the factory. Like, they didn't get to know them as part of that project and they didn't have anyone in their sphere and my parents were paper mill workers. So when I'm sitting there and listening to these people talk about the worker and their lack of wherewithal, I guess, there'll be a gracious way to say it right now, I was just appalled. I try to take that into any time we are building software in a way that honors all people. CASEY: Yeah. My favorite leaders are the ones that listen to their employees and the users. I am happy with my roles in leadership positions, but the thing that makes me happy with myself is listening and if I ever lose that, I don't trust myself to be a good leader, or manager. MAE: Totally. CASEY: I could. I know it's easy when you get promoted to stop listing as much. It's the incentive structure of the system. I wouldn't blame myself if I lost it, but knowing I value it and don't want to lose it helps me hold on to my propensity to listen. MAE: Yes, Casey! Totally that. CASEY: Sometimes people have asked me, “What makes you think you'd be good at leading this?” That is literally my answer is like, “Well, I won't forget to listen.” MAE: Yeah. JAMEY: I think that it's weird the way that people create this hierarchy of good ideas and better ideas and which idea is better and put that kind of value judgment on it. When really, when you're dealing with software and trying to create something that works for the people that are using it. It's not about whether your idea is good or bad, it's about whether it's the right one for that group of people. My background, my first tech industry job was in agriculture and so, all of our customers were farmers and people that worked at farms, To admit I don't know what it's like to work on a farm in that way, it's not a value judgment about whether you're smart, or good at programming, which people act like it is. It's just a true fact about whether, or not you've ever had that experience. [laughter] CASEY: Sometimes I run workshops where we think about all the pros and cons to different ideas and when we need it, we pull out a matrix. We get a spreadsheet that has columns and rows, and rows are the ideas. A lot of decisions are made with one column, naturally like, “What's the best?” You just say like, “1 to 10, this one's the best.” But when we break it out, we have lots of columns, lots of variables like, oh, this one's easier to build, this one's higher impact. And when we break it out even further, we can weight those columns then do the matrix math and people like that, actually. Even people who are math averse. They can fill in the numbers in each of the cells and then they trust the spreadsheet to do the thing. That gets us on the same page. It depends on the context, which columns matter, which factors are important and that can completely change the situation. Even if you all agree on this one's harder than that one, the outcome could be completely different. The columns, or the context in my matrix model. JAMEY: We're reading at work 99 Bottles of Object-Oriented Programming, which Mae knows because we work together, which we haven't said yet on the show. But we're doing a book club. Your description of the matrix columns and what is relevant reminded me of the thesis of that book because it's like, there are tradeoffs. It's not that one tradeoff is necessarily more valuable than another tradeoff, it's just like what makes sense for this context that you're using and building it in, then you have to think about it in a nuanced way if you want to come up with a nuanced answer. MAE: I am so grateful to and inspired by Sandi Metz. Her ability to distill these concepts into common sense terms is so genius and moving, welcoming, accessible. So grateful, so really glad you brought that up, Jamey. One of the things that really stuck out from various talks of hers that I've been to is even if you aren't changing that code, that code does not need to change. That's bad code, but it works. That's great code, [chuckles] like working code, and splitting some of the bikeshedding that we do on code quality with business impact is a teeter-totter that I really appreciate. JAMEY: I like the way it puts value on everyone and what they're working on. Because my big takeaway from starting to read this book has been that I tend to write fairly simple code because that's what I find easy to do. [chuckles] I always felt well, other people write more complicated code than me because they know more about X, Y, and Z than me and I don't know enough about it to write something that elegant, or that complex, or et cetera, et cetera, et cetera. I had placed this value judgment on other people's code over mine and to read about code that's dissecting the value judgments we put on it and determining hey, just because maybe it's not always the best thing to overengineer something Maybe it doesn't have to be because you don't feel smart enough to overengineer it. Maybe it can just be because that's not the right choice. [chuckles] MAE: Cool. JAMEY: I thought that was really valuable to think about. MAE: Love that, Jamey. JAMEY: Boost people's confidence, I hope because I think a lot of people need their confidence boosted. [chuckles] MAE: Yo, I had no idea what I was getting into as far as the mental health challenge of being a programmer. To maintain one's self-respect, especially as an adult who was successful in her career prior to then be like, there is a whole thing about the adult learner. But to have your entire day be dealing with things that are either broken, or don't exist yet, that's your whole day. Nothing works ever basically and the moment it does, you move on to the things that aren't, or don't exist. So it's so critical to try to remember and/or learn how to celebrate those small wins that then somehow feel like insulting that you're celebrating this is just some simple things. [laughs] And then it's like, why are we making a big fanfare? But those microjoys—I've never heard that phrase as opposed to microaggression, or something. Microjoys, if we could give each other those, it could go a long because the validation is a very different experience than I have seen, or heard about, or experienced in any other industry. It's a real challenge. JAMEY: Not only is everything broken, or doesn't exist. But once it's working, you never hear about it again until it's broken again. [chuckles] MAE: Yeah. [laughs] CASEY: That's so true and it's such an anti-pattern. At USCIS, you would have every developer, who was interested, see an interview—we're working on an interview app—watch the user use the app every month at least, if not more and they loved those. They saw the context, they saw the thing they just built be used. That's positive feedback that everyone deserves, in my opinion and it's just a cultural idea that engineers don't get to see users, but they should. They do at some companies and yours can, too. MAE: Yes, Casey! We are working on that at True Link financial as well. Figuring out how to work that more in so that we all feel part of the same team more and we're not like the IT crowd and in the basement and all we have to say is, “Hello, have you tried turning it on and off again?” [laughs] JAMEY: Casey, I love that because even as you were telling that story, I was like, “Yeah, it's useful to see how people use it because that'll help you make better decisions,” and blah, blah, blah, which I feel strongly about. And then what you actually said at the end was, “and you get satisfaction out of being able to see people using your thing.” I hadn't even thought of that dynamic of it. CASEY: Yeah. It's both, happier and more effective. That's the thing I say a lot. These user interviews make you happier doing your job and make you more effective at doing them both. How can you not? MAE: Yeah. JAMEY: What's not to like? [laughter] It's true, though about knowing that people use your app. I started in consulting and a lot of the things I worked on felt a little soul crushing and not because I thought that they were bad, or unethical in any way, but just like, who is this for? Like, who cares about this? One of my most joyful experiences was one of the other products that wasn't quite like that, that I worked on when I was in consulting was an app called Scorebuilders and it was for physical therapy students have a specific standardized test they have to take and so, it's study prep for this specific test. There's like two, or three and we had different programs for them. And then I, a few years after that was, in physical therapy myself, because I have back problems and they have interns from college helping them in the physical therapy office that I went to and they were talking about studying for their test, or whatever. I was like, “Oh, that's funny. I haven't thought about that in a while. Do you use Scorebuilders to study in?” They were like, “Oh yeah. We all use it. That's what you use if you're in this program,” and I was like, “Oh, I built that,” and they were like, “What?!” They were calling all of the other people from the next room to be like, “Guess what?” and I'm like, “This is literally the best thing that's ever happened.” [laughs] MAE: Yay! CASEY: Yeah! That's such a good story in the end, but it's such a bad story. You never got to meet anyone like that earlier, really? JAMEY: Yeah. CASEY: That's common, that's everywhere, but that's a shame. You can change that. [overtalk] JAMEY: I just realized since it was consulting and not like, I didn't work for Scorebuilders. CASEY: Oh, I'm sure. It's even more hard. JAMEY: Yeah. CASEY: I'm so glad you got that. JAMEY: Thank you. It happened like 5 years ago and I still think about it all the time. [laughs] Well, we've been having a great discussion, but we've pretty much reached the point in the show where it's time to do reflections and that's when everyone will say something that really stood out to them about our conversation, maybe a call-to-action, something that they want to think more about. So, Casey, do you want to start? CASEY: Yeah. I said this earlier, but this is my big takeaway is the word mutual aid can be more approachable if you think about it like people helping people and not a formal organization. Especially since it is, by definition, grassroots-y. There is no formal stamp of approval on a mutual aid group that formalizes it. That's pretty powerful. I'll be thinking about what communities I'm part of that do that through that lens this week and I challenge listeners to help and be helped sometime this week, both. JAMEY: I think one thing that I'm going to really try and keep in mind is what we were talking about, valuing yourself and the way that that helps the community. I really liked Mae's story about including yourself after other people and using that way to frame it in your mind. Because I think that that will make it easier and thinking about like, this is something I struggle with all the time. I think a lot of us do. So I think that I really want to take that one into my life. Next time I realize I'm treating myself unfairly, I want to think, “Well, how is this affecting the other people around me who probably don't want to see me to do that?” [chuckles] MAE: Thanks, Jamey. Yeah. I have so many answers of reflections! The one I know I'm going to use immediately is this most recent one of engaging with users using the things you're building as a reward and a way to be able to get microjoy. I'm definitely going to use that word now more, microjoys, but I agree with both of what you said, too. JAMEY: Well, Mae thank you so much for coming on and chatting with us. This was really great and I think people will really appreciate it. MAE: Yay. I loved it! Thank you both so much. What a treat! CASEY: I feel like we could keep talking for hours. JAMEY: I know. [laughter] This is how I feel after a lot of my episodes. [laughter] Which is always good, I guess, but. Special Guest: Mae Beale.

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 (https://exercism.io/) * Retrospectives 39:28 - Performance Reviews * Continuous Feedback * Brave New Work by Aaron Dignan (https://www.bravenewwork.com/) * Team of Teams: New Rules of Engagement for a Complex World (https://www.amazon.com/Team-Teams-Rules-Engagement-Complex/dp/1591847486) * Continuous Improvement & Marginal Gains “Start where you are. Use what you have. Do what you can.” ~ Arthur Ashe Empathy In Tech (https://www.empathyintech.com/) Corgibytes (https://corgibytes.com/) 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 (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.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 (https://www.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.

As menders working with legacy code, we are focused on identifying and reducing technical debt. But how much easier this task would be if the creator of the code or the previous maintainer left us some breadcrumbs to follow? A simple note on the rationale for a particular decision they have made or a warning about interconnected lines of code would take us a long way! Today we talk with Andrea Goulet, co-founder and Chief Strategy Officer of Corgibytes. Her empathy-driven approach to software development earned her recognition as one of the Top Ten Professionals in Software Under 35 by LinkedIn. She tells us about this lack of communication in software development, the phenomenon she calls the communication debt, and how its reduction can make the software more robust and its maintenance more efficient. When you finish listening to the episode, connect with Andrea via LinkedIn, contact her via Corgibytes' website, and check out her LinkedIn courses: Agile Software Development: Remote Teams and Creating an Agile Culture.  Mentioned in this episode: Andrea on LinkedIn at https://www.linkedin.com/in/andreamgoulet/  Andrea on Twitter at https://twitter.com/andreagoulet  Corgibytes website at https://corgibytes.com  Andrea Goulet, Agile Software Development: Remote Teams at https://www.linkedin.com/learning/agile-software-development-remote-teams  Andrea Goulet, Creating an Agile Culture at https://www.linkedin.com/learning/agile-software-development-creating-an-agile-culture    Changelog podcast with Katrina Owen at https://changelog.com/podcast/108  Katrina Owen, Exorcism.io at https://exercism.io  Indi Young, Practical Empathy at https://amzn.to/3jkDlLH* Legacy Code Rocks with Indi Young at https://www.legacycode.rocks/podcast-1/episode/270edc0e/practical-empathy-with-indi-young Ward Cunningham on technical debt at https://youtu.be/pqeJFYwnkjE Legacy Code Rocks with Arlo Belshee at https://www.legacycode.rocks/podcast-1/episode/c240c45d/naming-with-arlo-belshee Daniel Kahneman, Thinking Fast and Slow at https://amzn.to/3kceRW3* Legacy Code Rocks with Cyrille Martraire at https://www.legacycode.rocks/podcast-1/episode/2fd0fdeb/living-documentation-with-cyrille-martraire  Cyrille Martraire, Living Documentation at https://amzn.to/3kd2J7e* * Heads up! If you purchase a book through the links above, we will get a small commission which helps us continue to bring quality content to our Legacy Code Rocks! community. You won’t pay a penny more, we receive a small kickback, and you’re supporting our friends who wrote them. Everybody wins!

Staying agile is most important in times of crisis. After more than four months of Covid-19 disruption, it is clear that we are going through one of those era-defining moments. As the crisis drags on, we need to adapt and be more agile than ever. Today we talk with our own Andrea Goulet, Corgibytes CEO and Legacy Code Rocks co-host, about big changes we are going through here at Legacy Code Rocks and Corgibytes. So, take a listen and stay tuned!

Whether you're building something new or working on an existing product, you're bound to run into tech debt eventually (bonus points for when that debt is the direct result of your team's own choices). But it doesn't have to be terrible. In this episode Maggie talks with Andrea Goulet, CEO and co-founder of Corgibytes, about her path to founding a company, makers vs. menders, and the role that empathy plays in solving for tech debt. Like this episode? Be sure to leave a ️️️️️️⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends. You can connect with Maggie on Twitter @maggiecrowley @HYPERGROWTH_Pod

Whether you're building something new or working on an existing product, you're bound to run into tech debt eventually (bonus points for when that debt is the direct result of your team's own choices). But it doesn't have to be terrible. In this episode Maggie talks with Andrea Goulet, CEO and co-founder of Corgibytes, about her path to founding a company, makers vs. menders, and the role that empathy plays in solving for tech debt. Like this episode? Be sure to leave a ️️️️️️⭐️⭐️⭐️⭐️⭐️⭐️ review and share the pod with your friends. You can connect with Maggie on Twitter @maggiecrowley @HYPERGROWTH_Pod

You've done a lot of work to get yourself and your business to where you are today. You've learned new skills, implemented new systems, and started working with new people — but that's not necessarily going to get you over the next hurdle. Joining us to talk about what WILL get your organization over its next hurdle is Andrea Goulet, who is Co-Founder and Chief Executive Officer of Corgibytes and a prominent thought leader in the technology industry around three ideas: legacy code, communication, and empathy-driven development. Andrea is also the founder of LegacyCode.Rocks and the host of Legacy Code Rocks, a podcast dedicated to changing the way we think about legacy code.   Resources: Andreagoulet.com LinkedIn: www.linkedin.com/in/andreamgoulet Twitter: twitter.com/andreagoulet Corgibytes.com Take the course: Agile Software Development: Creating an Agile Culture Take the course: Agile Software Development: Remote Teams   Learn more and get the full show notes at: 3PillarGlobal.com

UPDATE: This is a re-uploaded version of the episode. The first became desynched during the recording process and again during the editing process. If you run into issues listening to this episode, please re-download to ensure you have the most up-to-date version. Sorry for the inconvenience!Are you tired of biopolitics yet? Then you probably shouldn't be watching Orphan Black. We're wrapping up our discussion of the series with discussions of racism, motherhood, and more!Some Links You Might Find Interesting:Orphan Black: Performance, Gender, Biopolitics edited by Andrea Goulet, Robert A. RushingIda B. Wells by Kate BeatonOrphan Black Season Five, “Manacled Slim Wrists”: What Man Has Done to Man by Everett HamnerOrphan Black Season Five, “The Few Who Dare”: Penetration, Selection, Sacrifice, Monsters by Everett HamnerOrphan Black Science Consultant Cosima Herter Breaks Down the Series Finale by Devon MaloneyOrphan Black Season Five, “Guillotines Decide”: The Community is the Smallest Unit by Everett HamnerOrphan Black Season Five, “Clutch of Greed”: Letting Go, Holding On by Everett HamnerOrphan Black Season Five, “One Fettered Slave”: Sexuality, Parenthood, Euthanasia by Everett HamnerOrphan Black Season Five, “Ease for Idle Millionaires”: Corporate Runs the Science by Everett HamnerLife, Death and Motherhood: The Legacy of Orphan Black by Alenka FigaSisterhood, Science and Surveillance in Orphan Black: Critical Essays edited by Janet Brennan Croft, Alyson R. BuckmanOur Website | Twitter | Facebook | Tumblr | Patreon | Merch

Ah, what a time to think about bioethics and biopower. We're taking a closer look at seasons one and two of Orphan Black, a BBC America show following a bunch of clones masterfully played by Tatiana Maslany. We're talking about biopolitics, we're talking about the body and personhood, and we're talking about genre.Some Links You Might Find Interesting:Orphan Black: Performance, Gender, Biopolitics edited by Andrea Goulet, Robert A. RushingThrills in the Dark: Orphan Black in the Shadow of Alfred Hitchcock by HafsahVictims and Villains: The Women of Orphan Black by Foz MeadowsSisterhood, Science and Surveillance in Orphan Black: Critical Essays edited by Janet Brennan Croft, Alyson R. BuckmanOur Website | Twitter | Facebook | Tumblr | Patreon | Merch

Legacy is something that you leave behind with the expectation that you are paving a path for the success of others. So why do we fear the word ‘legacy’ when referring to code? Jim Headley sits down with Andrea Goulet of Corgibytes who explains that legacy code is not always something to fear, but something that can be built upon and improved. View on Medium

There are many routes to c-suite but Andrea Goulet has taken one of the most non-traditional paths we’ve seen on CTO Connection. As the Co-Founder and CEO of Corgibytes, Andrea leveraged her experience in content and strategic communications to help a software remodeling company scale its business.Andrea is a big believer in the power of empathy – a word that’s not often prioritized in engineering. In this week’s edition of CTO Connection, Andrea explains how she makes empathy accessible to analytical audiences and the role empathy plays in creating a better experience and product.[00:24] - Andrea's path to CEO[03:25] - Communication debt[06:28] - Domain-Driven Design[08:06] - Keeping the knowledge close to the code[08:22] - Working Effectively with Legacy Code[11:43] - Continuous improvement[15:12] - Definition of done[18:05] - Experimentation and prototyping[20:53] - Slack at scale[24:05] - Teaching empathyCTO Connection is where you can learn from the experiences of successful engineering leaders at fast-growth tech startups. Whether you want to learn more about hiring, motivating or managing an engineering team, if you're technical and manage engineers, the CTO Connection podcast is a great resource for learning from your peers!If you'd like to receive new episodes as they're published, please subscribe to CTO Connection in Apple Podcasts, Google Podcasts, Spotify or wherever you get your podcasts. If you enjoyed this episode, please consider leaving a review in Apple Podcasts. It really helps others find the show.This podcast episode was produced by Dante32.

Andrea Goulet transforms software with communication and empathy. “Modernizing a legacy project is just as much about communication as it is about the code.”  Her mission is to remove the label of "non-technical" from the mindset of people who have been actively choosing not to attain technical skills. It is well within each person's ability to become more technical. On the flip side, when developers say, “I understand machines, but I don’t understand people,” her response is “That’s not true, you just haven’t practiced people skills.” Goulet hopes to see not only more women in agile in the future, but also other minority groups, especially women of color. Her words of wisdom: “We can’t get so wrapped up on the gender that we forget about all of the other intersectionalities of diversity and inclusion.” Accenture | SolutionsIQ’s Leslie Morse hosts. The Women in Agile community champions inclusion and diversity of thought, regardless of gender, and this podcast is a platform to share new voices and stories with the Agile community and the business world, because we believe that everyone is better off when more, diverse ideas are shared.Podcast Library: www.solutionsiq.com/womeninagile Women in Agile website: https://womeninagile.org/Connect with us on social media! LinkedIn: https://www.linkedin.com/company/womeninagile/ Instagram: https://www.instagram.com/womeninagile/ Twitter: https://twitter.com/womeninagileorg 

Deborah Hartman Preuss on Engineering Culture by InfoQ, Jessica Kerr on Legacy Code Rocks, Nir Eyal on Product Love, Dave Snowden on The Jim Rutt Show, and Mike Bowler on Legacy Code Rocks. I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. And, if you haven’t done it already, don’t forget to hit the subscribe button, and if you like the show, please tell a friend or co-worker who might be interested. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting October 14, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. DEBORAH HARTMANN PREUSS ON ENGINEERING CULTURE BY INFOQ The Engineering Culture by InfoQ podcast featured Deborah Hartmann Preuss with host Shane Hastie. Deborah was once an Agile coach. She wondered why she didn’t have anything in her toolkit to help people with the discomfort they were feeling with the change Agile was bringing. She didn’t find the answer in Agile, but she found it in coaching. Deborah says that one of the important things she does as a coach is to bring balance to the excitement of our dynamic lifestyles by helping us to slow down long enough to hear our own wisdom. Deborah tries to ask the biggest questions she can come up with. Typically that elicits a “Huh! I need to think about that for a minute.” Sometimes she has to say, “Don’t think about it. Feel it.” She sees her skill as being able to see what is in you, reflecting it back, and helping you notice what’s there. She says that when she can see herself clearly, she can stand in front of other people with less fear, more courage, and more love. She says we have good methods to bring, changes to bring, and skills to teach, but if we are stressed out when we’re doing it, that becomes part of our message. She says that for too long we’ve been told, ”Suck it up! Life is hard. You don’t have to love your job. The stress is part of the package.” In contrast, she believes that people who are not constantly stressed out can bring so much more to their work. Creating a joyful workplace starts with authenticity. When you are not trying to conform to somebody’s idea of who you should be, all that extra energy is left over to simply do great stuff. Authenticity both reduces stress and frees your uniqueness. Shane pointed out that authenticity requires vulnerability. Deborah says that is where leadership comes in: to create safety. A leader who doesn’t feel safe will have trouble creating safety for others. When we ask people to be vulnerable, it has to fall into a place of trust. That trust must be built first and that is a leadership skill. Shane asked how one builds that trust. Deborah pointed to the book Liftoff by Larsen and Nies (https://www.amazon.com/Liftoff-Start-Sustain-Successful-Agile/dp/1680501631). We build trust, she says, by talking openly about things and being accountable to one another. She also referenced The Speed of Trust by Stephen M. R. Covey (https://www.amazon.com/SPEED-TRUST-Thing-Changes-Everything/dp/1416549005) for building trust and repairing trust when it is broken. Shane asked about the state of diversity. Deborah said that part of the state of diversity right now is, “Oh look at how diverse we are!” but this is not the same as everyone feeling welcome to contribute their differences. Inclusion is honestly welcoming differences and giving those differences a proper reception. Shane asked about Ten Women Strong and Deborah described how the Ten Women Strong #WomenInAgile program lets women start from a common set of values from Agile. The group helps them to recognize their authenticity, celebrate it, and start designing to turn that into what they need. She described how the program helps women meet their own needs so that they fill the well and have more to give out to others. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/deborah-hartmann-preuss-on-creating-joyful-workplaces/id1161431874?i=1000449085542 Website link: https://soundcloud.com/infoq-engineering-culture/interview-deb-priuss JESSICA KERR ON LEGACY CODE ROCKS The Legacy Code Rocks podcast featured Jessica Kerr with hosts Andrea Goulet and M. Scott Ford. Jessica has been a software developer for twenty years. One of her obsessions is how, as developers, we have a unique power to change our own environment. It gets even more interesting when we change the environment our team works in.  They talked about symmathesy. It starts with systems thinking, where people realized that you can’t reduce a system to its parts, understand the parts, and expect that to extend to an understanding of the system as a whole. You need to understand the relationships between the parts. Anthropologist Nora Bateson took this idea further when she realized that it is not just that the relationships between the parts matter; each part is constantly changing as a result of its relationships to the others. She called this symmathesy. Scott asked how awareness of the symmathesy of software development has changed the way Jessica does her work. Jessica says that if you look at a software team as a socio-technical system of humans and software based on mutual learning, the trickiest part is the line between the humans and software. The interface between the humans and the software is low bandwidth and this has made Jessica appreciate the value of tooling and how tools need to be customized for every different software system and every group of people. Andrea asked how Jessica can explain those benefits to those who are in charge of budgets and in charge of predicting what will be delivered. Jessica says that people are starting to notice developer experience and developer productivity. For example, these topics show up at conferences more today than they used to. Jessica related the symmathesy of software development back to Andrea’s article on technical debt as communication debt. When you have a mental model of the software, that software is alive to you because you can change it. But if you add another person who doesn’t yet have that mental model, that software is dead or legacy to them because, to them, that software is not safe to change. They talked about 10x developers and how much of their productivity comes from being the original author of the system. Building a mental model from a system that somebody else wrote is much more difficult than writing a system yourself.  Andrea pointed out that from the original system author’s perspective, the other engineers seem less capable because they are struggling to understand something that seems obvious to the original author. Jessica says to always replace the word “obvious” with “I can’t explain it, but...” Jessica says she’s learned that whenever she thinks someone else is stupid, chances are they know something she doesn’t, and this is why their actions don’t make sense to her. Jessica is talking about avoiding the fundamental attribution error. She went on to talk about the difficulty of transferring knowledge. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/symmathesy-with-jessica-kerr/id1146634772?i=1000449136678 Website link: http://legacycoderocks.libsyn.com/symmathesy-with-jessica-kerr NIR EYAL ON PRODUCT LOVE The Product Love podcast featured Nir Eyal with host Eric Boduch. Eric asked Nir what inspired him to write his new book Indistractable. Nir says that Indistractable is a pro-human, pro-tech book about being able to control your attention and manage all sorts of distraction. Half the book is about how individuals can become indistractable and the rest is about how to help others or our environments become indistractable. When Nir was researching the book, he was surprised to discover that all of our behaviors are driven by a desire to escape discomfort. He says that if you want to become indistractable, you need to start with mastering your internal triggers.  We also need to be aware that the companies we work for are creating much of the distraction. If a company has the wrong kind of culture, that is, one that is high expectation and low control, it causes psychological discomfort. In these cultures, we strive for control by sending more emails, calling more meetings, and distracting ourselves and others. Another surprise for Nir was learning that technology at work is not the source of distraction. Distraction at work is a symptom of a dysfunctional workplace culture. For example, group chat apps like Slack are considered distracting. If the technology was the culprit, he asks, shouldn’t the people who work at Slack and use it most be the most distracted people? Slack doesn’t have this problem because they have a healthy workplace culture. This is relevant to managers because, unless you have three factors in your workplace, you will always have distraction. The three factors are: 1) an environment that provides psychological safety, 2) a forum for people to air concerns, and 3) leaders who exemplify what it means to be indistractable. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/nir-eyal-joins-product-love-to-talk-about-creating/id1343610309?i=1000449384509 Website link: http://productlove.libsyn.com/nir-eyal-joins-product-love-to-talk-about-creating-better-products-and-meetings DAVE SNOWDEN ON THE JIM RUTT SHOW The Jim Rutt Show featured Dave Snowden with host Jim Rutt. Jim asked Dave to explain Cynefin, the conceptual framework that Dave created to aid in decision-making. Dave says that Cynefin is based on a fundamental divide into ordered systems, complex systems, and chaotic systems. There is a phase shift between these types of systems rather than a gradation. An ordered system has a high enough level of constraint that everything is predictable. An example is such a constraint is how we all drive on the left in the UK and on the right in the US. This is called an “obvious” approach to order. The relationship between cause and effect is obvious. Another type of order is “complicated”, where there is still a right answer and, for experts, it may be obvious but, for the decision-maker, it isn’t. You sense/analyze/respond and you may discover the right answer with less precision. It is the domain of good practice, not best practice. If you over-constrain a system that is not naturally constrainable, sooner or later it fragments into chaos. If you fall into chaos accidentally, you no longer sense/analyze/respond, but instead you act/sense/respond. An example is Clayton Christensen’s notion of competence-induced failure: being so good at the old paradigm that you don’t see the change coming and the change becomes catastrophic for you. A complex system is one that has enabling constraints. Everything is somehow connected to everything else but the connections aren’t fully known. One concept is the dark constraint, referencing dark energy, where we can see the impact of something without knowing where the impact is coming from. You may want to compare this to the notion of symmathesy from Jessica Kerr’s appearance on Legacy Code Rocks. In a complex-adaptive system, the only way to understand it is to probe. One of Dave’s definitions of “complexity“ is: if the evidence supports conflicting hypotheses of action and you can’t resolve those hypotheses within the timeframe for a decision from the evidence, the situation is complex. In Cynefin, you don’t try to resolve it, you construct a safe-to-fail micro-experiment around each coherent hypothesis and you run them in parallel. That, in turn, changes the dynamics of the space and a solution emerges. The final domain is the domain of disorder. This is the state of not knowing which of the other systems you are in. It is a type of inauthenticity. If your natural tendency is to bureaucracy, you are likely to impose order when it is inappropriate. If your natural tendency is towards complexity and emergence, you may choose not to impose order when it would have been more appropriate to impose it. The essence of Cynefin is to say, “context is key.” Dave got fed up with management fads that said things like, “business process reengineering is universal” or “the learning organization is universal.” None of these are universal. They all work within a specific context. So part of the function of Cynefin is to decide what context you are in before you decide what method you will use. They went on to talk about Apex Predator theory, agent-based modeling, “anticipatory triggers”, artificial intelligence, Nicholas Nassim Taleb, and many other topics. I particularly liked what Dave had to say about what people who work on artificial intelligence should be trained in. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/ep11-dave-snowden-and-systems-thinking/id1470622572?i=1000449087845 Website link: https://jimruttshow.blubrry.net/dave-snowden/ MIKE BOWLER ON LEGACY CODE ROCKS The Legacy Code Rocks podcast featured Mike Bowler with hosts Andrea Goulet and M. Scott Ford. Mike has been writing code for thirty-five years. In the late nineties, he got frustrated with watching projects fail. He was working for a big bank and they would celebrate when they shipped something, but they knew it wasn’t what the customer wanted. Looking for something better, he found the XP community. He decided he needed to get better at the “people stuff.” This took him into neuroscience, psychology, hypnosis, neurolinguistic programming, and body language. He talked about Clean Language. Clean Language came originally from therapy. It was modeled on the style of therapy used by a therapist named David Grove, who himself never formalized his process. Clean Language is a set of questions that don’t contaminate the metaphors of the people you are questioning. He used the example of a metaphor of a head “exploding” with ideas to describe how to avoid contaminating a person’s metaphor. They talked about Judy Rees’s Lazy Jedi questions which are named that way because, if you only ask those two questions over and over, it is like you are using Jedi mind tricks. The questions are, “What kind of X is that?” and “Is there anything else about X?” If the metaphor is “my head is exploding with ideas,” the Lazy Jedi questions become: “What kind of exploding is that?” and “Is there anything else about that exploding?” Some people tell Mike that, as a software developer in a highly technical environment, they don’t use many metaphors. Mike begs to differ. He says that the metaphors are so deeply embedded that they don’t notice any more. A bug is a metaphor. A cache is a metaphor. Some metaphors are blatantly obvious, like “the band was on fire,” and some are really subtle, like, “I have a lot of bananas.” You aren’t using the exact definition of the word “lot” but are using it as a metaphor. They went through a clean language exercise in which Mike asked Scott about what he is like when performing at his absolute best and, based on his answers, got deeper and deeper into Scott’s metaphor. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/unconscious-behavior-in-coding-with-mike-bowler/id1146634772?i=1000447835119 Website link: http://legacycoderocks.libsyn.com/unconscious-behavior-in-coding-with-mike-bowler LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

Martin Thompson on Arrested DevOps, Dr. Carola Lilienthal on Legacy Code Rocks, Jeff Gothelf on Agile Atelier, Safi Bahcall on Coaching For Leaders, and Mike Burrows on A Geek Leader.  I’d love for you to email me with any comments about the show or any suggestions for podcasts I might want to feature. Email podcast@thekguy.com. This episode covers the five podcast episodes I found most interesting and wanted to share links to during the two week period starting August 19, 2019. These podcast episodes may have been released much earlier, but this was the fortnight when I started sharing links to them to my social network followers. MARTIN THOMPSON ON ARRESTED DEVOPS The Arrested DevOps podcast featured Martin Thompson with host Jessica Kerr. Martin and Jessica talked about the parallels between optimizing the performance of software systems and doing the same for human systems. Using ideas from queuing theory, they discussed the notion of adding small amounts of slack to a system to make it drastically more responsive. Martin connected Amdahl’s Law to the more general Universal Scalability Law, which is more comprehensive because it takes into account coherence cost, which is the time needed to reach agreement between parties working together. He added that Brook’s Law from The Mythical Man Month is the Universal Scalability Law by a different name. They talked about the difference between parallelism and concurrency. Parallelism, Martin says, is doing multiple things at the same time. Concurrency means dealing with multiple things at the same time, a definition Martin says he stole from Rob Pike. He further decomposed the universal scalability law into its parameters. One parameter represents whether you can subdivide the work (the contention penalty) and the other represents the time to reach agreement (the coherence penalty). If your team can reach agreement faster, they can get better throughput because they can have more parallelism with less concurrency. They got into a discussion of the importance of feedback in information theory. Sending information and not confirming reception is a naïve approach and this has been understood for a long time and yet software is still built that ignores this. Two phase commit is an example. If you study the two phase commit protocol in any detail, Martin says, you realize it is fundamentally broken, yet corporations don’t want to say that. They talked about how to design distributed applications in the presence of partial failures. Martin says to make your communications idempotent, give each message a sequence number, and use this sequence number to identify and ignore replayed messages. According to Martin, designing your systems this way is just good hygiene and professionalism. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/protocols-and-sympathy-with-martin-thompson/id773888088?i=1000444947737 Website link: https://www.arresteddevops.com/protocols/ DR. CAROLA LILIENTHAL ON LEGACY CODE ROCKS The Legacy Code Rocks podcast featuring Dr. Carola Lilienthal with hosts Andrea Goulet and Scott Ford. They talked about Domain-Driven Design. Carola said her company read Eric Evans’ book and immediately took to it. Talking to users, writing software in the user's domain, and using a common vocabulary fit with what they were already doing so they adopted it easily. They talked about Carola’s modularity maturity index. It consists of three areas of sustainability: 1) modularity, 2) hierarchy, and 3) pattern consistency.  Andrea brought up the fact that larger codebases aren’t necessarily more difficult to change as Carola found in her research. Carola says that, based on the three hundred systems she’s studied, systems under a million lines of code are often in a worse state than larger systems. Around a million lines of code, she says, something happens: either people start structuring the system and putting in guard rails that keep the product maintainable or the system doesn’t grow any more. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/sustainable-software-architecture-dr-carola-lilienthal/id1146634772?i=1000443349633 Website link: http://legacycoderocks.libsyn.com/sustainable-software-architecture-with-dr-carola-lilienthal JEFF GOTHELF ON AGILE ATELIER The Agile Atelier podcast featured Jeff Gothelf with host Rahul Bhattacharya. Rahul and Jeff talked about the intersection of Agile, Lean, and Design Thinking to find commonalities. They examined customer-centricity, measuring success, continuous testing, and the importance of having a hypothesis. Jeff had been working as a designer on waterfall projects for the first decade of his career and, on a good day, only saw 50% of his work get implemented. Ten years into his career, Jeff got exposed to Agile software development and it forced him to revisit his design process and his process for doing product development as a whole. Because Jeff was in a leadership position and had a boss that understood the new methodology, Jeff got the chance to run process experiments to learn what the best collaboration model was for him and his team. This became the basis of his book, Lean UX. Rahul asked Jeff how he would define Design Thinking. Jeff described Design Thinking as applying the designer’s toolkit to solve business problems. This includes empathizing with customers, brainstorming ideas, prototyping, testing ideas with customers, and iterating.  Rahul asked if there is a specific situation in which to apply Design Thinking. Jeff says that he has yet to find a client or an industry where customer-centricity, continuous learning, risk mitigation, experimentation, and iteration don’t make sense. Even when working with people at GE who make locomotives and working with organizations that make room-sized air conditioning units that sit on top of skyscrapers, Jeff was able to successfully introduce them to ideas like talking to customers, identifying risks, and continuously improving their product. Rahul asked how the principles of Design Thinking fit with the Agile principles. Jeff says that everybody thinks that Agile is its own thing, Design Thinking is its own thing, Lean Manufacturing and Lean Startup are their own thing. The tactical execution of those methodologies might be different, but at their core, Jeff says these methods all share the same principles.  They are all customer-centric. They all measure success as an outcome, as a change in customer behavior. They all focus on testing your ideas quickly and moving off of bad ideas quickly. And they all focus on continuously improving and iterating the thing you are making as you continue to invest in it. They then got into a discussion about the importance of measuring the impact on the user of the product you are building. Jeff says that, unfortunately, shipping the thing is still one of the major definitions of success for most organizations. But in a world of continuous software when you can push a software update five times a minute like Amazon does, delivering the thing is a non-event and it should be a non-event. We shouldn’t celebrate it. What we should celebrate is the change in customer behavior that tells us that we’ve delivered value. These are things like showing up at the website, engaging with the app, buying the product, telling your friends, whatever it is we care about for our product. This line of thought led to the quote above. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/episode-11-intersection-agile-lean-design-thinking/id1459098259?i=1000445718430 Website link: https://rahul-bhattacharya.com/2019/07/30/episode-11-the-intersection-of-agile-lean-and-design-thinking-with-jeff-gothelf/ SAFI BAHCALL ON COACHING FOR LEADERS The Coaching For Leaders podcast featured Safi Bahcall (author of the book Loonshots) with host Dave Stachowiak. They talked about what science has to say about the best ways to nurture new ideas. They started out with a discussion of children’s books and Safi’s first example of a loonshot was Dr. Seuss. He had just been rejected by every publisher he took his first story to when he ran into a friend in the street. This friend asked Dr. Seuss about what he had under his arm and when he found out it was a manuscript for a children’s story that Dr. Seuss was taking home to burn, the friend revealed that he had just taken a job at a publisher across the street and asked Dr. Seuss if he would like to come into the publisher’s office. The Cat In The Hat was born. Safi used the story of the moon landing as an illustration of the difference between a moonshot and a loonshot. A moonshot was Kennedy’s speech announcing that the United States would put a man on the moon by the end of the decade. A loonshot was forty years earlier when Robert Goddard suggested getting to the moon with liquid-fueled jet propulsion and was ridiculed by many, including the New York Times. The reason it is important to understand the difference is because Goddard’s ideas, though neglected by the Americans, were embraced by Nazi Germany. German scientists used Goddard’s ideas to build jet engines and planes that flew 100 mph faster than any Allied plane. The mistake of neglecting Goddard’s ideas was fatal. Companies often ask Safi how they can innovate and create new products while continuing to keep their original product or service competitive. He thinks about these situations using three metaphors: the ice cube, garden hoe, and heart. He starts by thinking about the artists who create new product ideas and soldiers to execute on turning those ideas into real products in the marketplace. The ice cube is a rigid phase that suits the soldiers and a melted ice cube is a fluid phase that suits the artists. Understanding the problem starts with the ‘beautiful baby’ problem. The artist sees their new idea as a beautiful baby. The soldiers look at the same thing and see a shriveled up raisin. They’re both right. The garden hoe comes from understanding that the failure point in most innovation is rarely in the supply of new ideas, it is in the transfer between artists and soldiers. Great leaders are those who think of themselves as gardeners managing the transfer between the artists and soldiers. The heart is about loving your artists and soldiers equally. When we lionize the artists as the media often do, we demotivate the soldiers. I liked what Safi had to say about the problem with following the standard advice about active listening. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/418-the-way-to-nurture-new-ideas-with-safi-bahcall/id458827716?i=1000443895174 Website link: https://coachingforleaders.com/podcast/nurture-new-ideas-safi-bahcall/ MIKE BURROWS ON A GEEK LEADER The A Geek Leader podcast featured Mike Burrows with host John Rouda. Mike talked about his career leading up to the writing of AgendaShift. He described the goal of AgendaShift as trying to introduce agility not by prescribing a set of practices or rolling out a framework but by getting agreement on outcomes and working out different ways of achieving them in an hypothesis-driven way. He then mentioned his newer book that he was working on at the time the podcast aired and has just come out this month, Right to Left. Right to Left is about working backwards from outcomes. John asked what the shift was that led to this outcome-focused approach. Mike said that while working in the government digital space in the UK, he witnessed rapid change. Instead of one supplier creating documentation for a new system, a second supplier building it, and a third supplier supporting it, and the whole thing being an expensive mess that disappoints its end users, he says they now have a system where projects will be halted if they are not serious about engaging with users, doing user research, understanding needs, and working iteratively to deliver evolving services. He says that if it can happen in the government space, it can happen anywhere. John asked about what a new manager coming from an individual contributor role would need to learn for dealing with the people side of managing projects. Mike recommended tempering any temptation to micro-manage. On his first day taking over a management position at UBS, he had people lining up at his desk looking to be micro-managed because that is how his predecessor worked. He told them that if this is how it is going to work, it is going to make him miserable and it is going to make them miserable and he encouraged them to self-organize. Mike’s second recommendation is to learn to value and respect people who come from other disciplines than technology, as he says in the above quote. John asked Mike to describe AgendaShift. Mike says that the best two words that describe it come from Daniel Mezick: it is an engagement model. Much like Daniel’s OpenSpace Agility, AgendaShift describes how change agents can engage with their organizations. In the Lean/Agile space, pushing Agile on people is self-defeating and creates more problems than it solves. Instead, facilitate outcomes that the people of the organization can agree on and start solving problems. AgendaShift starts with discovery. There are workshop tools to creating a high-level plan. Then they use an assessment tool for identifying opportunities to increase transparency, get workloads under control, or to engage better with customers. They identify obstacles and the outcomes hiding behind those obstacles. They use a “clean language”-based game to model a landscape of obstacles and outcomes and get people to think about the journey, their priorities, and what the key landmarks along the way will be. Apple Podcasts link: https://podcasts.apple.com/ca/podcast/agl-081-agendashift-with-mike-burrows/id1043194456?i=1000424584602 Website link:https://www.ageekleader.com/agl-081-agendashift-with-mike-burrows/ LINKS Ask questions, make comments, and let your voice be heard by emailing podcast@thekguy.com. Twitter: https://twitter.com/thekguy LinkedIn: https://www.linkedin.com/in/keithmmcdonald/ Facebook: https://www.facebook.com/thekguypage Instagram: https://www.instagram.com/the_k_guy/ YouTube: https://www.youtube.com/c/TheKGuy Website:

Andrea Goutlet is the Co-Founder and CEO of Corgibytes. Her mission is to empower communicators to code and coders to communicate.Andrea is a VCU Guest Lecturer, LinkedIn Contributor, and has been recognized by LinkedIn as a Top 10 Professional in Software under 35.Andrea is a wife, mom, blogger, international speaker, podcast host, and soon-to-be author. We discuss coding, leading in a male-dominant environment, and what it means to be a high-achieving woman. Tune into this week’s chat at LifewithChelsi.com, YouTube, Facebook, iTunes, or Google Play. You don’t want to miss Andrea's journey and advice to women interested in coding. #LifewithChelsi #ChatswithChelsi #Coding #WomeninTech #WomenWhoCode #CEO

Andrea Goulet Andrea Goulet is the CEO of Corgibytes, a software development shop dedicated to maintaining and modernizing software applications and has been named by LinkedIn as one of the Top 10 Professionals in Software Under 35. She’s the founder of LegacyCode.Rocks and hosts a podcast dedicated to changing the way we think about legacy code. You may recognize her from prominent industry publications such as the First Round Review, Hanselminutes, Software Engineering Daily, and more. Andrea is a sought after keynote speaker and presents regularly on topics that help business and technical teams collaborate better. Her two most popular talks are “Communication Is Just As Important As Code” and “Empathy Is A Technical Skill.”  In her spare time, Andrea enjoys blogging about the intersection of social science and software. She loves watching her kids explore the world and is a sucker for a good physics documentary. You can recognize her by the JavaScript tattoo on her wrist. https://corgibytes.com https://legacycode.rocks https://www.linkedin.com/in/andreamgoulet/ https://twitter.com/andreagoulet https://twitter.com/corgibytes

CEO and Co-Founder Andrea Goulet of the tech-debt fixing company, https://corgibytes.com stops by the People Stack to talk about building a community of Menders (https://www.legacycode.rocks/), knowing when and when your org needs Menders vs Makers, the Org Smells that show dysfunction in your org, how Conway's law impacts your tech debt and more. The book Andrea refers to in this episode is "The Five Dysfunctions of a Team: A Leadership Fable" by Patrick M. Lencioni. Here is an Amazon link to it: https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Lencioni-ebook/dp/B006960LQW Intro music is "I'm Going for a Coffee" (http://freemusicarchive.org/music/Lee_Rosevere/Music_For_Podcasts_3/02_Im_Going_for_a_Coffee) by Lee Rosevere, which is licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) Special Guest: Andrea Goulet.

Karen Straughan talks with Dave Rael about feminism, mens' rights, understanding people, gender relations Chapters: 0:52 - Karen, feminism, and mens' rights8:36 - Answers to oppression14:18 - Meaning of Equality21:42 - Karen on humility, ability, attraction, and her draw to the mens' movement35:54 - The power of words and the terms used by feminism43:22 - The importance of sexual consent45:31 - Harmful behaviors47:54 - Reproductive choices52:53 - Attempting to understand one another56:13 - "Nice guys" and the "friend zone"62:15 - Compassion for all parties involved in an unexpected and potentially unwanted pregnancy64:26 - The types of fiction that appeal to women and what it reveals about their desires72:20 - Privilege and empathy and the futility of seeking an ideal system83:35 - Mating habits of animals and their relevance to humans89:06 - "Seek first to understand, then to be understood" - Stephen Covey91:35 - Power and the source of your voice96:44 - Rape apologia103:39 - Violence toward women and men Resources: Karen's YouTube Channel Karen's Blog The Red Pill Cassie Jaye Christina Hoff Sommers on the Good Intentions Podcast Custody of Infants Act Married Women's Property Act "Big Red" from "The Red Pill: Raw Files" Swedish Government Bans Affirmative Action James Damore James Damore on the Good Intentions Podcast James Damore on the David Pakman Show James Damore on Freedomain Radio with Stefan Molyneux James Damore on the Rubin Report Tactics Young Women Use to Resist Condom Use When a Partner Wants to Use a Condom Sexually Transmitted Infection Hypergamy Statutory rape victim forced to pay child support Goofus and Gallant Slate Star Codex The Street Harassment Experiment - 10 Hours of Walking in NYC as a Woman Bill Burr Comedy Including References to Tiger Woods and Access to Sex Pareto Principle The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change - Stephen R. Covey Good Intentions Podcast Episode 1 with Andrea Goulet National Coalition For Men Conflict Theory Philip Davies If You See Jezebel in the Road, Run the Bitch Down (Paul Elam's article referenced in The Red Pill) Have You Ever Beat Up A Boyfriend? Cause, Uh, We Have (The Jezebel article to which Paul Elam was responding) I'll decide if you were raped, not you - Paul Elam Commentary on Rape Statistics

In this podcast Shane Hastie, Lead Editor for Culture & Methods, talks to Andrea Goulet & M. Scott Ford about their journey working together as a married couple and business partners, learning to collaborate and communicate despite having vastly different communication styles and viewpoints. Why listen to this podcast: - Effective communication is a competitive advantage - The system that you produce will only be as good as the communication structure you have in place while you build it - The importance of learning to speak each other’s language – the terminology of development and business is different and it is necessary to take the time and effort to learn the different language - The concept of “inception layers” relating to how intensively someone is concentrating on an activity and their level of openness to interruption - The value of writing a daily journal in a wiki to share what’s been happening and make progress and learning visible More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2zwXlnO You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2zwXlnO

This episode features conversations from Sustain 2017 at GitHub HQ with Richard Littauer, Karthik Ram, Andrea Goulet, and Scott Ford. Sustain was a one day conversation for open source software sustainers to share stories, resources, and ways forward to sustain open source.

This episode features conversations from Sustain 2017 at GitHub HQ with Richard Littauer, Karthik Ram, Andrea Goulet, and Scott Ford. Sustain was a one day conversation for open source software sustainers to share stories, resources, and ways forward to sustain open source.

Andrea Goulet talks with Dave Rael about subject that matter including government, race, empathy, understanding, and feminism Chapters: 0:10 - Who is Andrea1:56 - Accusations of lacking empathy8:33 - The intended audience of this podcast10:10 - The fundamental problem of human discourse in the world today14:12 - Politics - moderate and extreme17:34 - Defining feminism26:28 - Feeling alone in a crowd28:16 - Seeking to understand and dynamics of power34:23 - Confidence and the power of words36:51 - The complexity of human interactions, biases, and jumping to conclusions43:08 - Open-ended questions to open communication45:23 - Perspectives on sexuality49:35 - Objectification of women and the ways women can feel safe54:08 - The importance of consent70:16 - Validity of opinions and reciprocal understanding75:41 - Common ground76:35 - Context sensitivity of believing accusations - it's better to say they should be taken seriously than to say they should be believed84:35 - Men's Rights Activism86:37 - The power of government and the power of the people95:19 - Conclusion Resources: Magic Card Game CorgiBytes Andrea on Developer On Fire Technical? Non-Technical? Both! - Andrea Goulet US Senator from Virginia, Mark Warner US Represetative from Colorado, Mike Coffman Lessons From The Women's Strike - Andrea Goulet Virginia Commonwealth University (VCU) Abigail Adams urges husband to “remember the ladies” The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change - Stephen R. Covey The Confidence Gap Abigail Spanberger - Andrea's Friend and Candidate for Congress Men's rights movement Good Intentions Episode 0 - Dave Describing the intent of the show The 5 Love Languages: The Secret to Love that Lasts - Gary Chapman

Dave Rael articulates the intent of the Good Intentions Podcast Chapters: 0:00 - The name of the podcast and the nature of intentions1:23 - Opinions, fear, and the nature of modern discourse4:35 - An awkward formulation of Dave's outlook on the nature of evil6:15 - Expectations, emphases, and intentions for the podcast10:10 - The dire situation and fear of the consequences of speaking up12:22 - A New Hope13:23 - Expectations for Good Intentions and the approach15:32 - Fellow travelers Resources: The Good Intentions Podcast YouTube Channel - Episodes will be Live Streamed The Joe Rogan Experience “You keep using that word. I do not think it means what you think it means” - William Goldman via Inigo Montoya Political Parties in Norway The Dream of Bill Gates and Paul Allen The Cold Civil War - Angelo M. Codevilla Dave's Other Podcast - Developer On Fire Andrea Goulet Andrea Goulet on Developer On Fire 6 Type of Empathy

Guest: Andrea Goulet @andreagoulet Full show notes are at https://developeronfire.com/podcast/episode-248-andrea-goulet-square-zero

In this special episode recorded at the AATC 2017, Andrea Goulet speaks with Martin D. Lund, a scrum-certified software engineer who helps run an engineering team and a parent to three children on the autism spectrum. Founder of Agile for Autism (http://www.agile4autism.com/), a nonprofit initiative to help parents build educational and therapeutic programs for children with Autism Spectrum Disorders, Marty shares tips for working with someone on the autism spectrum and how he successfully implemented agile practices in his parenting.

Jim talks with Andrea Goulet and M. Scott Ford from Corgibytes -- specialists in software remodeling.  This is a continuing conversation on technical debt, the albatross around the neck of many companies.   Our conversation focuses on Makers vs. Menders, so come have a listen.

Special guest Andrea Goulet asks: Are you technical or non-technical? Learn More Carol Dweck on Mindset Andrea on Twitter and LinkedIn Andrea’s book: Becoming Technical More Agile in 3 Minutes Episode List | The Book Discuss Twitter | Facebook | agilein3minut.es Subscribe iTunes | Stitcher | Spotify | YouTube | RSS | Email Support Patreon | PayPal

STEMxm Episode 15-  Coder & CorgiBytes CEO, Andrea Goulet CorgiBytes | Technical? Non-Technical? Both! | Andrea's LinkedIn Graphene Girl talk barbie :( The Project Management tool we discussed = Slack The Movie - Inception One of the Places Andrea spoke at - Dot Net Fringe Here are some resources about (and how to overcome) Imposter Syndrome: Afraid of Being 'Found Out'? How to Overcome Imposter Syndrome Learning to Deal with the Imposter Syndrome Another take on Slate Sources for beginning your journey to learning code: CS50 at Harvard Computer Science for Everyone by the Great Courses (note: Great Courses are often available for check out at your local library) Free Code Camp Code.org Code Combat Kahn Academy Andrea mentioned research about how women have not historically applied for positions where they don't meet or exceed all the criteria. Here is some related research: Why Women Don't Apply for Jobs Unless They're 100% Qualified Are Women Too Timid When They Job Search   STEMxm is available on iTunes & Stitcher:

Andrea Goulet is the CEO of Corgibytes, a software development shop dedicated to maintaining and modernizing software applications. Named by LinkedIn as one of the top ten professionals in software under 35, Andrea is the founder of LegacyCode.Rocks, and hosts a podcast dedicated to changing the way we think about legacy code. She keynotes frequently about building a business based on balance, empathy, and trust; the perils of the technical/non-technical divide; and the technical philosophies around working with legacy code. In her spare time, Andrea enjoys helping other people learn how to code, and writing about the intersection of empathy and software. She loves watching her kids explore the world, and is a sucker for a good physics documentary. You can recognize her by the JavaScript tattoo on her wrist. Playing Small Moment Andrea says she still plays small sometimes, and she feels the anxiety that accompanies her fear may always be there for her. She finds herself focusing on the negative comments about her work, so she welcomes positive feedback about the impact she is making. The Wake Up Call After hearing her husband describe her as non-technical, Andrea realized she was the person who had been holding herself back. He had used the exact words to describe her as she had used to describe herself just days before. Style of Leadership Andrea encourages her team members to go outside of their comfort zones. She considers herself a gardener who sets seeds and lets them grow, and tries not to get in the way. What Are You Excited About? Andrea is ready to dedicate her time to writing a book and getting it published. She is also excited about the community of LegacyCode.Rocks. Current Business Challenge As Corgibytes continues to grow, Andrea is challenged with embracing the growth, while maintaining her original vision. Your Support System Andrea’s business partner Scott, who is also her husband, provides her with amazing support. Scott’s parents provide child care which gives them freedom to run their business. All of the team members are willing to do whatever it takes to get the job done. Leadership Practice Shared daily journals have been a transformative practice. Book to Develop Leadership Daring Greatly, by Dr. Brene Brown Nice Girls Don’t Get the Corner Office, by Dr. Lois Frankel Advice For Younger Self “Recognize no matter what you do, you are gaining an important lesson you can use later.” Inspirational Quote “No one can make you feel inferior without your consent.” ― Eleanor Roosevelt Links Website: Corgibytes.com Website: LegacyCode.Rocks Twitter: @AndreaGoulet LinkedIn: AndreaMGoulet GitHub: AndreaGoulet   Find more resources at https://womentakingthelead.com

Andrea Goulet is the CEO and Co-founder at Corgibytes. When Andrea was 24 years old, she started a consultancy where she worked with some of the world's largest brands. We talked about how she leveraged that experience to lead Corgibytes, a company focused on continuously improving codebases through software remodeling. Andrea also explained the process of working with legacy code, and the community she built around it called Legacy Code Rocks. We also explored topics on building inclusive environments in tech and her personal experiences in the field. I really enjoyed this episode because Andrea shares the path to starting Corgibytes as well as the early exposure she had to the world of computers when she was a kid. Show Notes: Legacy Code Rocks! Code: Debugging the Gender Gap Purple Cow by Seth Godin

Andrea Goulet is the CEO of Corgibytes, a software development shop dedicated to maintaining and modernizing software applications. Named by LinkedIn as one of the top ten professionals in software under 35, Andrea is also the founder of LegacyCode.Rocks,  and hosts a podcast dedicated to changing the way we think about legacy code. She keynotes frequently about building a business based on balance, empathy, and trust; the perils of the technical/non-technical divide; and the technical philosophies around working with legacy code. 

Pam Schmidt, Independent Consultant and Culture Creator and Andrea Goulet, CEO and Co-Founder of Corgibytes, LLC joined Chris Dyer to talk about the challenges of leadership and talent development.This show is brought to you by Talk 4 Radio (http://www.talk4radio.com/) on the Talk 4 Media Network (http://www.talk4media.com/).

Legacy code is code without automated tests. Most companies have lots of legacy code, and most developers don’t like working on legacy code. Why is that? What is it that makes legacy code so difficult to work with? And why does a large amount of legacy code slow down an organization so severely? Andrea Goulet The post Legacy Code with Andrea Goulet appeared first on Software Engineering Daily.

Legacy code is code without automated tests. Most companies have lots of legacy code, and most developers don’t like working on legacy code. Why is that? What is it that makes legacy code so difficult to work with? And why does a large amount of legacy code slow down an organization so severely? Andrea Goulet The post Legacy Code with Andrea Goulet appeared first on Software Engineering Daily.

Pam Schmidt, Independent Consultant and Culture Creator and Andrea Goulet, CEO and Co-Founder of Corgibytes, LLC joined Chris Dyer to talk about the challenges of leadership and talent development.

Andrea and I discuss how she incorporates her company's core values into her team’s selling efforts and how to use metaphors when selling intangible value.

Andrea Goulet is the CEO of Corgibytes, a software development shop dedicated to maintaining and modernizing software applications. Don’t be fooled by her decade of marketing experience; Andrea slings some solid code. She’s the founder of LegacyCode.Rocks and hosts a podcast dedicated to changing the way we think about legacy code. She speaks frequently about building a business based on balance, empathy, and trust; the perils of the technical/non-technical divide; and the technical philosophies around working with legacy code. In her spare time, Andrea enjoys helping other people learn how to code and blogging at Empathy Driven Development. She loves watching her kids explore the world and is a sucker for a good physics documentary. You can recognize her by the JavaScript tattoo on her wrist.

Andrea Goulet and her business partner Scott Ford love legacy code. No one is supposed to LIKE legacy code, right? Andrea and the team at CorgiBytes believes people are more than just makers - they are also menders. So how does one approach an old code base?

Andrea Goulet and Scott Ford from Corgibytes kick off the first episode of the Legacy Code Rocks podcast. In this episode, they discuss the idea of Makers (the developers who like to build things) and Menders (devs who like to fix things). 

Today I talk with Andrea Goulet about software "makers and menders." Andrea is the CEO of CorgiBytes. Listen in if you are interested in refactoring and green field projects, and the difference between the two! Today's episode is sponsored by Digital Ocean! Go to https://digitalocean.com to get started on cloud hosting. Use the promo code DEVELOPERTEA at the checkout after you create your account to get a $10 credit!