Podcasts about corgibytes

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

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.

This week we're taking you to the hallway track of All Things Open 2023 in Raleigh, NC. Today's episode features: Heikki Linnakangas (Co-founder of Neon and Postgres hacker), Robert Aboukhalil (Bioinformatics software engineer) working on bringing desktop apps to the web with Wasm, and Scott Ford who loves taking a codebase from brown to green at Corgibytes.

This week we're taking you to the hallway track of All Things Open 2023 in Raleigh, NC. Today's episode features: Heikki Linnakangas (Co-founder of Neon and Postgres hacker), Robert Aboukhalil (Bioinformatics software engineer) working on bringing desktop apps to the web with Wasm, and Scott Ford who loves taking a codebase from brown to green at Corgibytes.

M. Scott Ford, the CTO of Corgibytes and host of the Legacy Code Rocks podcast, discusses managing dependency freshness. SE Radio's Sam Taggart speaks with him about why dependency freshness is important to ensure that your code has all the latest bug fixes, how exactly to measure dependency freshness, and some of the insights that teams can gain from monitoring freshness over time. Brought to you by IEEE Computer Society and IEEE Software Magazine.

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.

Are you working on Ruby on Rails Applications that are constantly on fire, overwhelmed by technical debt? What if you were building Technical Wealth instead? Learn which tools & strategies to work with legacy code effectively, remove dead code, and leave tech debt behind.Listen to and watch our conversation with M. Scott Ford and learn how to build technical wealth, enjoy working with legacy code, tools, and strategies to remove dead code, and how thrive in a world of makers as a mender.About our guestM. Scott Ford is the Co-Founder & Chief Code Whisperer of Corgibytes, where he has quietly led a software maintenance revolution for the past decade. Where most people find nothing but frustration, shame, and bugs in legacy code, Scott has centered his work around his genuine love of software modernization and helping others use joy, empathy, and technical excellence to make their systems more stable, scalable, and secure.Scott's ideas have been featured in books such as The Innovation Delusion and as a guest lecturer at Harvard University. Scott is the author of three courses on LinkedIn Learning: Dealing With Legacy Code And Technical Debt, Code Quality, and Clean Coding Practices.He is the host of the podcast Legacy Code Rocks and enjoys helping other menders find a sense of belonging in a world dominated by makers.Episode Links Watch the interview on YouTube Episode Notes and Links Legacy Code Rocks Legacy Code Rocks Slack Group (weekly meetups at 1pm EST on Wednesdays) MenderCon (May 10th, 2023) CorgiBytes Scott's LinkedIn profile Scott's Twitter profile Scott's Github profile How to Improve Code Quality on a Ruby on Rails Application Ruby Code Quality with Ernesto Tagwerker Get to Senior Chapters00:00 intro 01:57 makers vs menders 03:43 menders love improving legacy codebases 05:06 greenfield projects are glamorized 06:30 greenfield-legacy projects 09:07 working with legacy code: tools & strategies 09:53 building technical wealth vs tech debt 14:29 "the big rewrite" never works 18:54 removing redundant code22:56 features not used very often 25:41 static code analysis tools 27:23 charge extra for features used by fewer customers 30:52 find code that is never used 34:09 code audit with feature flags36:07 enforce code quality with tests and CI 39:26 measure code quality over time 41:09 churn, complexity, and CodeClimate score 42:43 bus factor45:59 working with makers 51:24 hanging out with other menders 53:27 follow hexdevs

In the previous episode, Scott Ford, the co-founder and CTO of Corgibytes, a company focused on modernizing legacy code, sharedHis interest in legacy codePatterns he has seen evolve in solution development over the yearsUsing metaphors of archeology and home renovation in the context of understanding and breathing new life into old softwareAnd moreThis is the second part of the conversation with Scott Ford, where he sharesThe origins of his company corgibytes, with a focus on helping companies take something that already exists and make it betterThis includes analyzing the structure of the code, test suites etc or the way the teams are structured and workflows, to help address a business needHow his team focuses on the craft more than the urgency to ship something out quicklyHe talks of the mindsets for makers and menders in the software development spaceThat it is no a binary, but more of a spectrum that one can and may need to move inMany makers may want to move on after 80%, when they may be bored; the menders can step in and help complete the remaining 20%Why he felt the need to have a co-founder and how he found the ideal partner, in business and lifeHow he started with developing websites and small apps, and then pivoted to the current focusThe process they have evolved over the years for the inspection and understanding existing codeUsing Cyclomatic complexity, duplication of code, coverage, churn etc, to identify hotspotsHis career tipsM. Scott Ford is the Co-Founder & CTO of Corgibytes, where he has quietly led a software maintenance revolution for the past decade. Where most people find nothing but frustration, shame, and bugs in legacy code, Scott has centered his work around his genuine love of software modernization and helping others use joy, empathy, and technical excellence to make their systems more stable, scalable, and secure. Scott's ideas have been featured in books such as The Innovation Delusion and as a guest lecturer at Harvard University. Scott is the author of three courses on LinkedIn Learning and he is the host of the Legacy Code Rocks! Podcast.https://www.linkedin.com/in/mscottford/ 

In this conversation with Shiv, Scott Ford, the co-founder and CTO of Corgibytes, a company focused on modernizing legacy code, sharedHow he found his interest in legacy code after about 10 years of working in various roles and organizationsBeing given bugs to fix, in his early career - and after addressing them well, taking on more responsibilitiesDeriving joy in fixing code or refactoring more than just writing new featuresHaving a trigger moment while watching a PBS show on home improvement ‘This old house', that gave due credit to the earlier architects and designers and respect their decisions, rather than calling the old work as bad or stupidWanted to add new functionality to something that may not have been thought of in the original design - and apply the same principles to modernizing old softwareHow he navigates and understands documentation or lack of it - for the old codeHow documentation is best recorded after an experiment is concluded, when writing code experimentally and incrementallyLikening modernization of code to an archeologist's way of workingWhen boredom might make the code more complex, to keep oneself challenged, even to solve simple problemsSeeing flips back and forth between static and dynamically typed languages influencing styles of coding over the yearsSimilarly, centralization and decentralization themes also keep switching from time to time over the yearsHow he leverages his strength of being a polyglot - among computer languages, by actually working on real world problems using these languagesScott's experience and thoughts on being an entrepreneur will be covered in the next episode.M. Scott Ford is the Co-Founder & CTO of Corgibytes, where he has quietly led a software maintenance revolution for the past decade. Where most people find nothing but frustration, shame, and bugs in legacy code, Scott has centered his work around his genuine love of software modernization and helping others use joy, empathy, and technical excellence to make their systems more stable, scalable, and secure. Scott's ideas have been featured in books such as The Innovation Delusion and as a guest lecturer at Harvard University. Scott is the author of three courses on LinkedIn Learning and he is the host of the Legacy Code Rocks! Podcast.https://www.linkedin.com/in/mscottford/ 

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

Imagine if you could refactor legacy code with a single CLI command? Well, you can, at least if you are working with PHP.  Today we talk with Matthias Noback, a long-time web developer and the author of several programming books, including Rector - The Power of Automated Refactoring, which he co-wrote with Tomáš Votruba. Matthias tells us how to use Rector in your daily workflow, how it automates repetitive maintenance and refactoring tasks, and what is the potential of this approach for other programming languages.  When you finish listening to the episode, connect with Matthias on Twitter, visit his website at https://matthiasnoback.nl, and grab his book Rector - The Power of Automated Refactoring.  Mentioned in this episode: Matthias on Twitter at https://twitter.com/matthiasnoback Matthias' website at: https://matthiasnoback.nl Rector - The Power of Automated Refactoring at https://leanpub.com/rector-the-power-of-automated-refactoring/ The Mikado Method at http://mikadomethod.info Corgibytes at https://corgibytes.com

Scott's story took us from learning BASIC, C/C++, and Object PASCAL in high school to quitting jobs every seven months because it wasn't fun. Scott told us about his love for the puzzle of discovering something new; and how it took him more than ten years to realize that this was what he longed for. He then described how he created his company Corgibytes, created the "Mender" term, and has not been quitting his job every seven months since.Here are the links from the show:https://www.twitter.com/mscottfordhttps://www.linkedin.com/in/mscottford/Virtual Meetup https://twitter.com/corgibyteshttps://www.slack.legacycode.rockshttps://www.legacycode.rockshttps://mendercon.com/https://www.poetryloverspage.com/poets/kipling/palace.htmlhttps://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/CreditsCover Heliotrope by Blue Dot Sessions is licensed CC BY-NC-ND 4.0.Your host is Timothée (Tim) Bourguignon, more about him at timbourguignon.fr.Gift the podcast a rating on one of the significant platforms https://devjourney.info/subscribeSupport the show

There is a lot of buzz around Kotlin, a new Java-based programming language that many think might eventually replace Java. But is all this talk justified, and are the predictions of replacement realistic?  Today we talk with Duncan McGregor and Nat Pryce, the authors of Java to Kotlin. They reveal to us all the advantages of Kotlin, why and when you would want to transition to it from Java, and how to facilitate the refactoring in a painless and efficient way. When you finish listening to the episode, connect with Duncan and Nat on Twitter and check out their book Java to Kotlin.  Mentioned in this episode: Duncan on Twitter at https://twitter.com/duncanmcg Mat on Twitter at https://twitter.com/natpryce Kotlin to Java, 1st edition at https://www.amazon.com/Java-Kotlin-Duncan-McGregor-ebook/dp/B09CT5KZLM Kotlin Programming Language at https://kotlinlang.org  Joshua Bloch, Effective Java, 3rd Edition at https://www.amazon.com/Effective-Java-Joshua-Bloch-ebook/dp/B078H61SCH/ref=sr_1_1?crid=3CG84SQ8VU5ET&keywords=effective+java+josh&qid=1653917364&s=digital-text&sprefix=effective+java+josh%2Cdigital-text%2C260&sr=1-1 Corgibytes at https://corgibytes.com

We all want our code to be stable and resilient to future challenges. But we need to strike the right balance between testing our systems and the cost of failure. This is much harder to achieve than it sounds.  Today we talk with Melanie Frank, Managing Vice-President of Cyber Engineering at Capital One. Her teams innovate boldly to secure the enterprise while obsessing over excellence. Before Capital One, Melanie worked at Honeywell at NASA Goddard Space Flight Center, where she tested software that conducted scheduling, command, and control for space network communication satellites.  Drawing from her experience in the aerospace and financial industry, she tells us about the significance of testing and how to do it right for your product.  When you finish listening to the episode, connect with Melanie on LinkedIn.  Mentioned in this episode: Melanie on LinkedIn at https://www.linkedin.com/in/melanie-frank-06b3675/  Capital One at https://www.capitalone.com  NASA Goddard Space Flight Center https://www.nasa.gov/goddard  Corgibytes at https://corgibytes.com  Empathy in Tech at https://empathyintech.com 

We all strive to write an ideal code - easily readable, functional, and clean. We use many tools to achieve this. However, we often forget why we need our code to be tidy.  Today we are talking with Samuel Taggart, President of GDevCon N.A. and the owner of SAS Workshops. Sam is a natural teacher, and he enjoys sharing what he learned with others. We talk with Sam about the tools and methods that make our code clean - refactoring, retrospectives, and style guides. While they are all meant to keep us and our code in check, we forget that these tools and methods also need to be under control. Sam reminds us of a crucial question that will help us do just that.  When you finish listening to the episode, connect with Sam on LinkedIn and Twitter and visit the SAS Workshops website at www.sasworkshops.com.  Mentioned in this episode: Samuel Taggart on LinkedIn at https://www.linkedin.com/in/taggartsam/ Samuel Taggart on Twitter at https://twitter.com/sasworkshops GDevCon N.A. at https://gdevconna.org SAS Workshops at https://www.sasworkshops.com Mikado Method at https://understandlegacycode.com/blog/a-process-to-do-safe-changes-in-a-complex-codebase/ Legacy Code Rocks - Living Documentation with Cyrille Martraire at https://www.legacycode.rocks/podcast-1/episode/2fd0fdeb/living-documentation-with-cyrille-martraire Zettelkasten Method at https://zenkit.com/en/blog/a-beginners-guide-to-the-zettelkasten-method/ Corgibytes at https://corgibytes.com 

Imagine if you could compare concepts side-by-side between a programming language you know and one you don't. Well, now you can! Today we talk with Sarah Withee, a polyglot software engineer, international tech speaker, and robot tinkerer. Sarah is also the author of Code Thesaurus, the polyglot developer reference tool. She tells us about the reasons behind the creation of the thesaurus, its continuous development, and what you can do to make the thesaurus even better.  When you finish listening to the episode, connect with Sarah on Twitter and LinkedIn and check out the Code Thesaurus project on GitHub.  Mentioned in this episode: Corgibytes at https://corgibytes.com  Sarah in Twitter at https://twitter.com/geekygirlsarah  Sarah on LinkedIn at https://www.linkedin.com/in/sarahwithee/  Sarah's website at https://geekygirlsarah.com  Code Thesaurus at https://codethesaur.us  Code Thesaurus project on GitHub at https://github.com/codethesaurus/ 

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!

When you enter a legacy code base, where do you start? How do you analyze the code? How do you set it up for safe changes? How do you know when to stop cleaning? Join Chris and Austin as they not only discuss legacy code refactoring and mending with M. Scott Ford from Corgibytes, but also share some analogies for code technical health and safety. Video and show notes: https://youtu.be/2ay2kQu6PZw 

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.

For most teams, dependency freshness is a pain that is often ignored. “If it works –don’t change it” is the prevailing attitude, but as a lot of applications become web-focused, dependencies inevitably start gaining traction. Why does dependency freshness matter, and how do we proactively stay on top of it?  Today we present Freshli - the dependency freshness tool we have been working on. The microphone goes to the team involved: Cassandra Carothers, Technical Sales Manager here at Corgibytes, and Catalina De la Cuesta, Chris Cumming, and Dave Farinelli, our Lead Code Whisperers. The Freshli tool captures historical libyear metrics about a project's dependencies. Freshli stays alongside your codebase and works together with code quality tools, showing where your project is going overtime. It is designed to work with multiple languages, and it currently supports Ruby, Perl, Python, PHP, and .NET.   If you are interested to know more about Freshli, make sure you reach out to our team on LinkedIn after you’ve listened to the episode. Mentioned in this episode: Cassandra Carothers at linkedin.com/in/cassandramcarothers/ Catalina De la Cuesta at linkedin.com/in/catalinadelacuesta/  Dave Farinelli at linkedin.com/in/dfar-io/ Chris Cumming at linkedin.com/in/chris-cumming/ Libyear at https://libyear.com Corgibytes at https://corgibytes.com Freshli at GitHub at https://github.com/corgibytes/freshli-lib 

In this episode, we sit down with Scott Ford from Corgibytes to talk about how he's built and managed a fully remote team. https://www.cavesocial.com/scott-ford

At the helm of Corgibytes is Scott, who has been called the “Bob Vila of the internet.” Scott is a polyglot developer who, at last count, is fluent in over twenty programming languages. Scott's love of software restoration and remodeling began in college where he and his team were responsible for retrofitting the testing tools for the X-31 jet fighter. Since then, Scott has maintained a test-focused approach to his work and found the most joy in projects where an existing codebase needed to be improved. In addition to fixing old code, Scott enjoys anime, reading sci-fi fiction and comic books and spending time with his family. And yes, he did have a Corgi, her name was Ein, and if you recognize that reference, they might just give you a discount. Check out Scott's company below: Website: corgibytes.com LinkedIn: https://www.linkedin.com/company/corgibytes-llc Twitter: https://twitter.com/corgibytes ...and as always, enjoy the listen. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/archdevops/support

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!

Most, if not all, of the legacy projects feature monolithic application architectures. However, moving to containers can bring many benefits: consistency down the pipeline, no-touch deployment, better support for decomposing the monolith - to name just a few. Today we talk with our own Ben Johnson. Ben is the lead code whisperer at Corgibytes and a developer with over 20 years of experience. We chat about containerization - what benefits does it bring, what challenges could you encounter in the process, which tools are best suited for the job, and what methodology proves to be most reliable. When you finish listening to the episode, make sure to connect with Ben on LinkedIn or contact him via the Corgibytes website, and read his fantastic blog about containerization. Mentioned in this episode: Ben on LinkedIn at https://www.linkedin.com/in/benrj Corgibytes at https://corgibytes.com Ben Johnson, Moving a Monolith to Kubernetes at https://corgibytes.com/blog/2020/02/27/monolith-to-kubernetes/?utm_content=buffer43f15&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer  Dockers at https://www.docker.com Heroku at https://www.heroku.com/home

In this episode we speak to M. Scott Ford, the Chief Code Whisperer at Corgibytes. A company that focuses on mending software. He is also the host of one of our favorite podcasts - Legacy Code Rocks. This episode is all about legacy code, a topic that is really near and dear to the RPA community. Just a note this episode may get technical but have some solid lessons for anybody dealing with tech that frightens them.

The idea of a lone developer coding without social interaction or good communication skills is a thing of the past. See the video of the interview here: https://dojo.nearsoft.com/interviews/code-communication-scott-ford-corgibytes/

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

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.

Robby speaks with M. Scott Ford, CTO and Chief Code Whisperer at Corgibytes and co-host of the Legacy Code Rocks podcast. They discuss the difference between Makers and Menders, how to prioritize a technical debt backlog, and how to provide feedback to other developers.Helpful LinksM. Scott Ford on TwitterCorgibytesLegacy Code Rocks[Book] Lehman’s Laws of Software Evolution and the Staged-Model[Book] Radical CandorSubscribe to Maintainable on:Apple PodcastsOvercastSpotifyOr search "Maintainable" wherever you stream your podcasts.

To survive, every software needs to change over time. However, if the changes are too steep, the survival might quickly turn into a demise. Today we talk with our own Scott Ford, co-founder of Corgibytes and co-host of the Legacy Code Rocks, about Lehman's laws - a set of principles that explain the forces which push software systems to change and the forces that restrain that change.  Hear from Scott how Lehman's laws can help you in your work and get to know Scott a little bit better.

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

Scott Ford Scott Ford: I love fixing and maintaining existing applications. So much so, that I've built a team of like-minded people to focus exclusively on legacy code projects. Through my business, Corgibytes, I help businesses breathe new life into old code. I call this software remodeling. Just like how you wouldn't bulldoze your house if you wanted to update your kitchen, it's often more cost-effective to improve the app you already have instead of starting over. I specialize in test-driven development and love working in many languages, platforms and frameworks. RUBY DEVELOPMENT I've worked on ruby projects using Locomotive, Spree, Mongoid, Devise, Radiant, Nokogiri, and obviously Rails, Sinatra, cucumber and rspec. I was a testing fanatic before ruby, so the testing tools are what brought me here. CODE MECHANIC Since I can remember, I've been allured by the mysteries of machines. I was a constant tinkerer. So much so that my mother instilled the "you're not allowed to take it apart unless it's already broken" rule because I dismantled one too many appliances just to analyze the innards. So, it's almost natural that I love fixing bugs in software. I love participating in the open source community because I get giddy whenever I come across a bug and fix it. Even though ruby is my favorite, there's no limit to the languages I'll employ to fix bugs. Over the past fifteen years, I've fixed bugs using Bash, Basic (wow - that takes me back!), Batch, C, C++, C#, Delphi, Fortran, Java, JavaScript, Lisp, Objective-C, Pascal, PHP, Prolog, Ruby, Scheme, VB.NET, Visual Basic, and many more. SOFTWARE CRAFTER Software as craft? It's how I see the world. But instead of plaster or wood, my medium is bits and bytes. I constantly seek ways to refine coding techniques, find creative fixes, and deliver elegant solutions to all sorts of business problems

M. Scott Ford is the founder and chief code whisperer at Corgibytes, a company focused on helping other companies with legacy code. Topics include: How M. Scott Ford got into forming a company that works on legacy code. Technical debt Process debt Software testing The testing pyramid iterative development kanban readable code and readable test code Special Guest: M. Scott Ford.

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

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.

In today's edition of the Safety At Speed Podcast, I spoke to the co-founders of Corgibytes - Andrea Goulet and Scott Ford. The goal of Corgibytes is to help different groups and organizations modernize their existing software applications. In many cases, organizations have existing programs that they have been using for a long time, and which provide a ton of value, but are not always easy to work on. Corgibytes cleans everything up, and makes it more modern and secure. They call themselves the “Code Whisperers”.

At KubeCon 2016, Elliott had a moment to speak with SAP Labs' Nishi Davidson about some of the driving principles behind large-scale adoption of Kubernetes at SAP. Ecosystem partnerships tend to spring organically when thought-leading organizations agree that the same set of problems needs to be solved. As Nishi points out, secure, orchestrated service scaling is definitely one of those problems.

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

Catalina De la cuesta is a Lead Code Whisperer at Corgibytes. She brought with her 18 years of deep embedded systems experience, a college-level teaching and entrepreneurship background, as well as a lifelong learner mindset. In this episode, we discuss what it’s like to be a mender full-time, what led Catalina to Corgibytes, and why diving into binary files can be fun.

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/).

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 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!

Chad talks to Scott Ford, founder & COO of Corgibytes, about the business of software remodeling/retrofitting, and finding value and beauty in old code. Corgibytes Scott on Twitter