Hey everyone and welcome to Developer Tea, my name is Jonathan Cutrell and today I have the pleasure of interviewing Andrea Goulet. Andrea is the CEO of Corgi Bites. Corgi Bites is an agency that is entirely focused on maintaining legacy code. We talk about all of the implications and the hard parts and the cool parts of doing just that. We also talk about the opposite side of that and how a makers versus menders plays out for developers. Thank you so much for listening to today's episode and thank you to today's sponsor digitalocean.com. If you are looking for a cloud hosting service, digital ocean is a fantastic solution to that problem. Both Andrea and I have used digital ocean. We talk a little bit about digital ocean later on in the episode. So for now I want to go ahead and get straight into the interview with Andrea Goulet. Thanks so much for coming on the show Andrea. Thank you. I'm excited to talk to you about makers versus menders. We've had a few conversations before we decided to sit down and actually do the episode. So I'm ready to jump right in if you are. Sounds great. So tell everyone who's listening what you do every day at Corgi Bites. Yeah. So I'm the CEO. So that's in charge of really maintaining the vision and our growth. And the way that we started was I partnered with a really good friend from high school Scott. And he's one of the most brilliant software developers I've ever known. Just is one of these people who just has magic fingers in watching him code. It's like the matrix. And so we partnered together in 2009 because he had kind of the real technical side of things but he wanted help marketing. And over the years, we have developed a value proposition where the only thing that we do is we work on existing code bases. So kind of our tagline is old code new tricks. So we do a lot of refactoring test driven development. So we build custom APIs. We do integrations between different systems, if a company acquires another company and there's custom software that all needs to talk to each other. We're the ones who instead of advocating for a complete rewrite, we're the ones who will get in and make everything work together. And we kind of coined this term software remodeling. So kind of the idea that you wouldn't bulldoze your app a lot of times, it makes a lot more business sense for you to just go ahead and build some integrations. And I think that's a theme that we're seeing a lot. One of the key things that we found was that the types of developers who like working on these problems, we initially thought that maybe Scott was just kind of a freak accident. He really was the only developer on earth that enjoyed refactoring. Because most Developer That I've interacted with over my careers, they like doing the new stuff. And I know Jonathan, you've talked that that's kind of where you fall in. Definitely, yeah. And it is. So we found that developers really kind of fit into two camps. There are the folks who like doing the new stuff. And so if you map that to kind of the product lifecycle where there's the development of a product, then you introduce it to the market. So you're kind of building MVPs and then kind of getting some real quick feedback. Those are the types of Developer That we traditionally think of. But there's products that then after they've been introduced, you maintain them. And so the next phases in the product lifestyle, there's growth where you're focusing on scaling and then also maturity where you've established a market position. And now it's about retaining customers more than it is necessarily acquiring new ones. And you're trying to keep your competitive advantage. So I came at it from the business side and was able to kind of put all of this together. And we realized that there's like a dotted line where the developers who like working on those first two phases, the development and introduction, there's the makers. And you see this all the time, there's maker fairs and maker fest and make magazine. They're the people who craft new things, right? They take some raw materials and they put it together and it doesn't have to be perfect and it doesn't have to be ready for market. But they've made something new is the idea. Yeah. And it's like they get this real rush from seeing the thing. And then usually it's like, okay, I know it's duct tape and prototype. But I did it. I figured out the problem and then they want to move on to the next problem. They don't necessarily want to take it to be polished or finished. Sure. Almost just like one step beyond prototype. Yeah. Yeah. We call it sometimes the 80% solution. Sure. And it's funny because with that 80, 20 rule, the last 20% of the project ends up taking 80% of the time sometimes because there's a lot that goes on in that polishing thing. And I think that's part of the reason why developers, well, a lot of Developer Tend to think that the maker phase is the fun part is because they feel that momentum, that 20% effort, getting them 80% of the way there, that feels like momentum. But then they hit that brick wall, which is where the mender takes over. Yeah. And menders really approach their development a lot differently. So for example, Scott and kind of an analyzing Scott and how he works and how he's different from traditional developers, we really identify, we started calling him a mender. And so for Scott, what he likes to do is he gets into the code base. And instead of focusing on like a big, massive goal, like I want to hit this or I want to present this or I want to get this to an investor or something that you would traditionally think about, you know, a big launch. Instead, he loves doing small wins throughout the day, which is why he really is a big advocate for test-driven development because he says every time a test passes, you know, it starts as failing. And then I see a test passed. I get a small little jolt of happiness. And so instead of focusing on a really, really big win, it's more about kind of a slow and steady and stable pace and just polish things over time. And focusing on those really small wins, he gets a lot of joy from, you know, reducing complexity. So he'll go in and, you know, we do a lot of refactoring. And what that does is it enables our clients to develop features faster. So a lot of times they'll hire us to kind of work alongside their team. So sometimes I use this like, I have, I have small kids. And so we hired a service to come in and help me clean my house because it just, because it's not that I couldn't. And it's not that I didn't know how. It was just like, I didn't want to spend my time doing that. And I found that there's a lot of developers who kind of think the same way. It's like, given the amount, given the time that I have in the day, I would rather be building new features rather than, you know, cleaning up, you know, and refactoring. And so we built our business saying, hey, we really like refactoring. We really like doing all of the, you know, reducing technical debt and doing all of those things you're supposed to do. So we can, we end up working alongside. And sometimes it's for a long period of time. Sometimes it's just to kind of clean up a specific problem or introducing a test tool or, you know, something. But it's been a lot of fun. And we've found that Scott is not the only developer out there. We actually have a whole team of folks. And it's awesome because all of us really get jazzed about solving complex problems. And those small wins over time, it's a fun, fun environment to work in, even though it sounds boring. Well, as a developer, I think that's an interesting, like, distinction to make, right? Because a maker versus vendor, this is a very different type of work environment. I'm wondering, you know, what kinds of things do I need to determine about myself? To decide which side of that fence I fall in. Because I think that that last 20 percent, a lot of the time the maker feels like they're supposed to, you know, see this thing through to its polished state, but it feels like a lot of, I don't know, it feels laborious to get there. And so I'm wondering, you know, what, what aspects should I be considering about myself to determine, do I like working on something, you know, in its early stages only or would I make a good vendor, for example? Do you like to maybe start from a blank canvas? And what's, when you first think about solving a problem, is it let me go build this thing or is it, let me go find what's already out there and see if there's something I can improve upon? Because that's something I've seen all of our developers do is, you know, consistently, they'll say, what open source technologies are already out there that I can dive into and make better? Or, you know, is there something that I can fork off a GitHub that I'll make it do what I need to? Or is it, you know, let me go ahead and build a new app from scratch? So I think that's probably a good differentiator. And then also just what motivates you, you know, are you the type of person where you tend to procrastinate until the very last minute and maybe get just this big rush of emotion over kind of a one big event? And then you kind of, you take a break and then it's kind of another big rush to a big project. You know, does your energy level do better, like, are you more motivated when your energy is like a roller coaster? Or do you prefer to kind of have things be steady? If it's that like slow and steady development and just, you know, small, simple wins, you know, and it's like, I don't want all the drama. I really like it when I can keep things very controlled. Those are usually some signs that you might be a mender as well. Also, that you just like refactoring. I found that people, like, they're one of the biggest things that I've seen is that people say, I love editing code. I love, you know, kind of keeping the purpose but making the code a lot more readable and enjoying that process. And there's no shame in enjoying that. I think that's one thing that we found too. Yeah, it's, there is a negative perspective of, you know, legacy code is almost a curse word in the world of development for, especially for particular languages or frameworks. The idea of, you know, maintaining legacy code that was written, I don't know, with an old framework on Java or something, that to me sounds awful, right? But, but the truth is it's, it doesn't have to be. That's what Andrea and her team have found is that, you know, there are people who have a much stronger sensibility or a much much stronger propensity to do that, mending that maintaining of those older code bases. And there's nothing wrong with that. In fact, if you are listening to this show right now and you have always wondered why people hate legacy code so much, you could be a mender. Yeah. It could be that you are cut out to manage those things because there are going to be projects over and over and over and in 10 years from now, the stuff that I'm writing today or the stuff that another company is writing today, it will be considered legacy code if it's still online, if it's still, you know, in the market. So there will need to be some people who appreciate the code that I'm writing today in 10 years from now and can refactor it to be up to standards from what it will be then. Well, I would argue that it's not even 10 years. It can be 10 months. Oh, yeah, that's so true. The way that I think of legacy code and there are so many definitions out there, like Michael Feathers defines legacy code as code that doesn't have tests written, you know. And so if you look at legacy code, there's so many out there and it's purposefully kind of had this negative connotation. But the way I think of legacy code is anything that's existing, right? Like, if you write something and you just and you are planning on maintaining it, you have a legacy code base, like an existing code base is something that is legacy, you know, anything that you shipped, in other words, right? Absolutely. And so what we see a lot, like the types of clients that tend to come to us are ones that are like really high growth startups. So they kind of go through this prototyping phase where it's like, they're not really focused on the quality and it doesn't make sense to really focus on polish when you don't even know if your idea is going to have a market fit, right? It makes a lot of sense to kind of throw stuff together and you might not be doing the best practices in terms of code and how it looks and, you know, you might have things that, you know, are a little bit more complicated than you'd like, but it's about speed to market at that point. Sure. To MVP at that point, yeah. Yeah, absolutely. And so what happens is then you're successful. And now you're starting to encounter different problems and you're saying, okay, how do I make this scale? How do I make this easily consumable? You know, how do I integrate with other systems? And then refactoring all of the sudden becomes a lot more important. You know, how do I make it so that, you know, I'm running things and my technical debt isn't slowing me down from feature development. We see that. So we have some clients where they have a very complex architecture and they need to have that broken down so that they can run their features faster. But it didn't make sense. Like the architecture that they chose made perfect sense at the time and it's incredibly successful, right? It got them to where it needs to be. And now they just need to remodel it because they're faced with a different problem. It's very similar to, you know, if you bought a house and, you know, you originally thought it was going to be kind of your starter home, but then you decided you really liked it and you loved the schools and your families there. And now it's like, well, we've got, you know, new issues that we need to compensate for. So you might build an addition or you might, you know, renovate it or something like that. It's a similar kind of concept, but it's something that I think a lot of people who are in the software world usually hear that developers will always advocate for a complete rewrite. I don't know that that's always the case. Sometimes that may just be the loudest people. Yeah. Yeah. Well, in my backyard, I have a bunch of dead grass and I've told my wife over and over, we need to just rip up all of this grass. I don't think that we need to try to, you know, revive it because, you know, if you pull the grass up, there's rocks and there's clay and it was really poorly done to begin with, right? I feel like, you know, there's a, there's a big weight on me. Refactoring my backyard is not an option. You know, like, there is some level of incomprehensible amount of work that would have to go into trying to make grass grow on rocks and clay. But somebody, somebody could come into my backyard and make that actually happen. And somebody would actually be really, they would really enjoy doing that. I'm sure. But I feel like that's a pretty good, a pretty good allegory for what we're talking about here with software development as well. Yeah. And I think that's one of the things that you can look at too. It's like, when do you remodel? Because we've definitely had clients come to us and, you know, they're using a technology stack that maybe is older, but they haven't gotten so far into the process where it's like, look, you're young enough and you don't have so many users where it makes sense for you to just go ahead and scrap what you've gotten start over. We've totally advocated for that. It's not that you never want to remodel. It's just that you want to always consider that as a possibility. And so what we do is we kind of weigh what features do you have and then what features do you need and then what's the overlap is kind of the justification that a remodel makes sense. If you have all these features, you know, built in, but you need something that's totally different, you know, then it doesn't make a lot of sense to remodel. But if there's a lot of overlap between those, then it makes sense to go ahead and remodel because there's likely going to be significant costs savings. Sure. Yeah. So I want to talk about today's sponsor with you, Andrea. Yeah. And you've used digital ocean before. Yeah. What did you, what kind of projects did you use digital ocean with? Yes. We spin up prototypes every once in a while and I think they're really, really easy as provisioning servers. Yeah. You know, the pricing is really reasonable. The UI is super simple. It's really easy to use. And so when we just need to kind of spin something up and test something out, it's really nice. Yeah. It's $5 to spin up a server. Yeah. Yeah. And so it's great just to be like, hmm, is this going to work? Let's test it out. I know one of the things that we also like to is that just knowing that the data sits on an SSD, that's really, really good too. Yeah. Yeah. It's fast. There's a significant amount of bandwidth, even on the low tier of what they offer. Yeah. I think there, I mean, it's just a great service. And they are a sponsor of this show, but I would probably talk positively just as much about them if they weren't. So it's a great service digital ocean.com. And actually we have a code in the show notes that you can find. The code is Developer Tea and you can actually get a $10 credit for new accounts when you go to digital ocean.com. Of course, again, that will be in the show notes at spec.fm. Make sure you check those notes out because everything else we're talking about here, including all the things that Andrea has mentioned about Corgi bytes. And I think, Andrea, you have a slide deck that I can put in those show notes, correct? Mm-hmm. Yeah, absolutely. So some more information about this idea between Maker and Mender will be in the show notes as well. So we begin to digital ocean for sponsoring today's episode. Okay, so I think that makers can learn something from Menders. And I know that we, this is going in a slightly different direction than where we've been kind of residing for the rest of this conversation. But we've been talking about this idea of refactoring and making your code ready to be extensible and that kind of stuff. I really think that makers can start by building sustainably a little bit better than we currently do on the whole. So I want to ask you kind of what we could do as makers to prepare our code bases better to hand off to a Mender. Yeah, so I think focusing on making your code readable is huge. So Arlo Belshe, who's a developer over at Microsoft, he has a great article on how naming is a process. And so when you're talking about naming variables, naming functions, things like that, I really, really like kind of the approach that he takes when it comes to naming variables. Because if you name things like Foo, we've seen that where it's like, you know, there's no thought into really describing, you know, what things do. Because ideally, you know, the code in itself should describe what the system does. You shouldn't need any outside documentation to describe what outside documentation should be used to talk about the how and the why, especially. I think the why gets left off a lot. But in terms of what the code base does, really the only documentation that you would ever need in an ideal world is the code base itself. And a lot of times that comes down to making sure your variables are named really well. And then also, you know, avoiding things like duplication. So if you find yourself copying and pasting things a lot, you know, that might be a good sign that you need to write a method for it. And, you know, so spending some time there just to think, I think, you know, it's common things like the DRY principles that don't repeat yourself. And taking the time to really think and kind of spot patterns and say, you know, have, you know, am I doing this repetitively and then taking the time to go ahead and fix that before you kind of move forward. But it is so tempting because it feels really fast when you're in that maker mode that, oh, let me just copy and paste all those stuff. But in the long term, you know, a lot of duplication, a lot of complexity that really, really bogs down your system. Just like swiping that credit card of technical debt. Absolutely. Yeah. I mean, just building sustainable software. We talked about this on the show in many different formats. I talk about the DRY principle. I also talk about when to break the DRY principle. There are so many different things that you can learn to be a better software developer, even in the maker phase, to hand the stuff off to Menders, in my opinion. And I think a lot of that stuff is the stuff that Menders are the best at, quite honestly. In terms of being able to refactor things, being able to make code clear and extensible and flexible, all of those things seem to be the anti-debt if you want to call it that. Yeah. And if there's a really great video by a friend of mine, Luw Allen Falco, and also Woody's will on practical refactoring. And it's a two hour video. So if you're interested in kind of learning more about specifically, if you can counter some of these things, what are some really good tips and techniques? That's a really, really fantastic resource to look at. And it's a YouTube video. So that's always fun too. So you can kind of see the code being interacted with. That's one of the challenge, I think, when it comes to books sometimes, is that they're not quite interactive enough. But there are definitely a ton of books out there as well on refactoring. But I really like the video of the WELM put together too. Yeah. Refactoring is its own thing altogether. I mean, we could talk about that for hours on hours and still not be done. There are historically a ton of books on the subject, design patterns, all of these things that go into the idea of making better software. And so that's what we're all trying to do together. But this idea of Maker versus Mender allows you to kind of shift. And it's possible that there are developers out there who have seasons that they go through where they are more a maker than a Mender. There are many times where I actually really do appreciate that day-to-day, small wins, being able to see all my tests pass. And there's nothing wrong with that either, the kind of like split personality developers or something. I find myself the same way when it comes to extroversion and introversion. My wife and I talk about this all the time. I have this extrovert side and this introvert side. There's nothing wrong with having a maker side and a Mender side. Of course, there are a set of skills that you need to have really home-dined to be a good one of either of those things. And that's actually the next thing I want to ask you, Andrea. You guys actually work with any technology at all. You don't have any restrictions on what technologies people walk in the door with. And I want to know, first of all, how do you make that work when there are so many possible technologies? It seems like a huge risk to take to me and I'm interested to hear how you guys handle it. But secondly, I'm also interested to know what would be the technologies that you think Menders need to learn. They need to invest time in learning. So yeah, on our website, it says any framework, any platform, any language. And we worked together for about five years before I actually felt comfortable putting that on the website. So yeah, you're right. There's a lot of risk. And, you know, Scott is fluent in, I think the last, currently, had was like 20 plus languages. It's not that we know already every single language that's out there or every single framework or every single platform. But we hire for people who are incredible problem solvers and who can learn a language very quickly. And so those are the types of people that we look at. So some examples of how this has come in handy is, you know, we have some clients where they're trying to build APIs, but they're trying to integrate them with systems where there was a language and it was a proprietary within an organization. And so there's very little documentation. But it's kind of like software languages, you can look at them very similar to kind of the romance languages about how like French is a derivative of Latin. And so is Spanish and English, but it has some dramatic influences. You know, if you look at the software, you know, landscape as well, software languages tend to follow the same thing. So, you know, you can, you know, yeah, you can see the influences of different languages in different spaces for sure. Yeah. So we look for folks who are really, really good at patterns and who can identify and say, oh, okay, well, you know, this looks very similar to C-Sharp, but they've done these things differently. And I can understand why. So being able to kind of hone in really quickly. So yeah, so that's kind of where we said any framework, any platform, any language. And the other thing too is just that we noticed that the problem in the marketplace today is how do I integrate things together? You know, I would say that five, ten years ago it was how do I build these apps? And now the business problem that I see is how do I get my app to talk to, you know, as many other apps as possible because that's going to bring value to the customer. And that's how I'm going to keep my users. Like, if you look at Slack, for example, I think one of the reasons Slack beat out HIPCHAT and some of the other folks is that their API is so extensible and so well-documented, so easy to just plug into things. And so the more that you have, you know, from a business perspective, the more things that you have integrated into an existing system, then it becomes sticky, right? And so right now we have so much built with Slack that it would be a more of a burden for us to leave. Mm-hmm. Yeah, that makes sense. Yeah, so I think integrations are really, are really where things are going. And there are people who need to integrate with those systems that, like I said, they're, you know, it's not like Python or Ruby or something where it's kind of well-documented, they're, you know, really more obscure. Totally makes sense. And so I guess the second question I asked, which is what kinds of technologies do you think are suited for vendors to learn? And add on to that is when you are looking to hire a developer, is there any kind of like base knowledge things that you look for? What I'm hearing is you want people to understand how APIs work, maybe some API standard ways of doing things, but is there anything else that you look for in a developer to be a vendor on your team? Yeah, so we really look at, you know, production experience with a variety of languages. And I think the definitely for our more senior folks, what we like to see is kind of big paradigm shifts across the career. So, you know, we see where maybe they were doing, you know, ASP.NET and they were working with C Sharp and, you know, maybe some visual studio over here and then it was like, you know what, let me completely switch and I'm going to learn Ruby on Rails. Rather than, you know, kind of staying in kind of the Microsoft stack and becoming a real expert there, we're looking more for kind of big swings across kind of philosophies of languages. So being able to understand like when, because each language and each framework, like you're really just tools, right? And so if we're looking at this as remodeling, the more tools you have, the more options that you have as well. So and it's about picking the right tool for the job. And so understanding, you know, Pearl is really great if it's, you know, if you're solving this very one specific problem, you know, and if you've got web apps, you know, it's probably not the best tool to use, you know, you may want to use something like, you know, Ruby or even go or rest or swift now. But if you, like I've seen it before where, you know, there are folks who maybe come from the Microsoft world and they're ASP.net and then it's like, well, I want to stick just with.net and, but then they become so comfortable there. It's like, well, let me use web forms and it's like, ah, that's a technology that's maybe, you know, three or four years old and yet kind of was the best practice, but maybe isn't right now. It's that feeling of like always wanting to stay on top of technology and learn something new, but diving in enough where you've actually got production experience and you've built something that's whole and kind of maintained it. That's kind of what we look for across somebody's resume. Sure. That totally makes sense. And I think the, the difficult part and the exciting part of that is that you have to know, you know, how much to learn and where to draw the line and say, well, I know enough to be functional with this. I know enough to be able to refactor things, but I'm not an expert. I'm maybe, maybe you're an expert in, you know, building APIs in general. Maybe you're an expert on some other technology, but being an expert in every one of these technologies is obviously, you know, you can't do it. You don't have enough time in your life to be able to develop expert level knowledge of that many different things unless those different things are really not that complex. And then I don't think the term expert really applies anymore to be an expert in something that thing has to be sufficiently complex. And so, you know, anything with sufficient complexity takes a significant amount of time in your life, not just like per day, but in your life over a period of time to really become an expert in. So to be a good vendor, you have to be able to let some of that stuff go so that you can move on and become more flexible, become more adaptable to new technologies. Yeah, and it's understanding to, you know, what are the benefits? You know, I think it's also understanding the why behind different technologies and why would you choose this language over another? It's not just that, oh, you know, go is the new fast, awesome thing and everybody's talking about it, so I want to go use it. It's really kind of taking the time and saying, okay, let me understand this language. You know, let me go, like there's a great tool, I don't know if they have Go or Swift or Rust on there, but there's a great tool called exorcism.io. And so, you know, you can go in and kind of learn how to give in feedback and they've got different problem sets with lots of different languages, but really, you know, kind of understanding why you would use a different language over another. Yeah, definitely. Well, this has been incredibly interesting. I have two more questions that I like to ask all the people who come on my show. I'm going to go ahead and ask those as we wrap up this interview. Cool. Number one, if you could provide advice to every developer or any developer, what would that advice be? I would say to watch, there's a TED talk by Carol Dweck about adopting a growth mindset. And for me as a developer, that was transformative. I'm a very high achiever. I was somebody who always wanted to get straight A's and there is this idea now. It's not an idea, but they're showing the concept of what's called neuroplasticity, which means that your brain changes based on what you've learned. And so your brain changes when you learn things. It's not fixed. You're, you know, the amount of knowledge that you have is not fixed. It's because, you know, you may be self-taught or, you know, you come from a development background that doesn't mean that you can't learn a new skill. So for example, we, one of the things we demand of our employees is we have a core value that says communication is just as important as code. So we're looking for developers who aren't just good at the technical side, but they're also really good at communicating in English and documenting their rationale. And I have so many Developer That get really nervous about that, but it's all about practice. And, you know, just as I come from the business side and I've learned how to code, you know, you can learn whatever you want to learn. And there's enough out there, but it starts with the belief that you can learn it. And it starts with really adopting that growth mindset. Yeah, I mean, learning is a huge topic on the show. Of course, you've heard me say this a million times if you've listened to the show. And I totally advocate for this position of neuroplasticity and constantly learning and constantly adding to, you know, that portfolio of skills and doing so in a way that is, that compounds those skills with each other, you know. And so if you've learned one skill that is about the web, then learning another skill about the web could actually make the first skill more valuable. And conversely to that, if you learn a skill that is way off in left field, well, now you have what's called a diverse portfolio. And so there's a lot of really interesting things that you can do by building up this different kind of cross-platform learning and understanding things in different areas and understanding how they relate to each other. The more you have, the more you have to draw on, right? The more knowledge, the wider the knowledge is, the more you have to draw on. So the things that you learn, for example, the things that I have learned, or use myself as an example, the things that I have learned about functional programming with Haskell, have made a big difference on the way that I write Ruby and JavaScript. And so if you think that you only need to become an expert in one language, I think. And don't quote me, well, do quote me on this. I would say that to become an expert in one language, you have to have the context of the other languages. And I think that's incredibly important for anybody who is in this field, maker or mender. Mm-hmm. Absolutely. So the second question that I ask all of my guests here on Developer Tea, what do you wish more people would ask you about? This one's always a hard one. Can I tell you what I wish people didn't ask me? Sure. That'll work. So people stopped asking me if I know how to code. I almost asked you if you are an engineer of some sort. Yeah, I get asked that all the time. So I look like your typical marketing girl, right? Like I'm perky and I smile and I do come from a marketing background. And Scott, darkroom glasses beard, like he kind of fits the stereotype of a developer. Sure. Nobody asks him if he codes they just assume that he does. Nobody ever, ever asks him. They always assume. And I wish that people would assume that I code. Sure. Interesting. Yeah. Because every time somebody asks me if I code, it makes me feel like I'm not good enough. And I'm already feeling like as a woman, you know, as somebody who's coming from a non-technical background, I already have this kind of feeling of imposter syndrome a little bit. Sure. And when somebody asks me, so do you code? So it makes me feel like, am I not good enough? Is my code? It's like a test. Yeah. And so actually not what you're talking about? Yeah. Yeah. So I actually got a JavaScript tattoo of function on my wrist. Nice. So just to show people, not only do I code, I am made up partially of code. Well, it really was more of something for myself because I'm like, am I really a developer? Like I've been doing this for eight years, right? I'm constantly going, I read a lot more code. And I'm usually the person that people come in to be a duck, right? Where it's like, you know, I'm stuck on this problem. Can you kind of help me figure out where the problem is? So I do a lot of that. You know, but I write my own code and it's pretty good, I think. Well, you've been writing code for eight years, you've said? Yeah. Yeah. So I'm sorry. Yeah. But everybody asks me. They're like, you know, and it's kind of demeaning. I think it's to not assume that just because somebody looks a certain way that they do or don't write code. Because it's a skill just like being able to, you know, do a podcast or write an English paper or form a hypothesis or, you know, like it's just a skill. And just because somebody looks a certain way doesn't mean that they do or don't possess that skill. Oh, yeah. I've experienced this personally at Whiteboard on many occasions. We have people at Whiteboard who write code that you would never guess if you were to meet them, you know, just out randomly on the sidewalk, you would never say that he seems like a software developer or she seems like a software developer, not at all. Like you would not expect that at all from the people that you would meet from Whiteboard. And it's, it is very interesting to see, you know, what that kind of stigma has become for both sides of that fence. And you're on one side of that fence and some of the guys and girls at Whiteboard are on the other side of the fence. Yeah. Yeah. And it's like, I don't, I don't really want to change who I am or how I dress or how I talk to fit this stereotype just because I have this skill. Yeah, I totally agree with that. Well, that's really interesting and insightful. And perhaps hopefully for some people kind of convicting words because it can be, it can be difficult to, you know, to try to escape these assumptions that we have built in into our minds about, you know, what, what kinds of people are supposed to do, what types of things in this industry and really just get rid of them. It's not worth. Diversity is a good thing. Diversity in your knowledge, diversity on your team, like diversity just bottom line is a really awesome thing to have. Yeah. Dave Rupert actually talked about this at CSS DevConf. And I'm not going to try to summarize him because I'm going to, I'm going to butcher it. He would hear it and probably laugh at me. But definitely go and listen to his talk if it is online and if not ask somebody who went because it's, it is hilarious the way he frames it. And then he really does get into it in a very good way because Dave is just like me. He's a middle-aged white guy, right? Like, and there's so many of us in this industry and we have to step up and be actively against that stigmatizing or people asking Andrea and people like Andrea, do you actually code? You don't seem like somebody who, that's such crap. Like stop doing that. Just diversity in general is getting a lot better because I would attend Ruby conferences six, seven years ago and I was one of maybe three women in the room, which is a benefit because it's the only time I think that the bathroom line is much shorter for women than it is men. That is very true. But, but in general now I'm seeing, you know, it's probably 10, 20 percent women, which, you know, it's, that's a lot of growth in just, you know, kind of five years. So I see a good trend and I just hope it continues. Yeah. And in fact, at CSS DevConf, they had a blind review process for talk submissions and it turns out actually about half of the talks were by women and it was great. It was, I mean, it diversity was definitely visible at that conference more than I have seen in the industry in large in a while. Yep. That's awesome. That's awesome. Well, thank you so much Andrea. I really have enjoyed this and I love this idea between maker and vendor. Where can people find you online? They can find out more at corgibytes.com. Perfect. Thank you so much. All right. Thank you so much for listening to today's episode of Developer Tea. I hope you enjoyed the discussion with Andrea as much as I did and I also hope you got a lot out of this discussion about makers versus menders as well as Andrea's comments about diversity in this industry. It is super important that we are all aware of these things. So thank you so much for listening. Thank you to today's sponsor digital ocean.com. Once again, make sure you go and check out the show notes at spec.fm. You'll find links from today's episode as well as the special code for digital ocean to get the $10 credit. Thank you again to digital ocean for sponsoring the episode. If you are enjoying Developer Tea, make sure you subscribe. It is the easiest way to make sure you do not miss out on future episodes of the show. Thanks again for listening and until next time, enjoy your tea.