Hey everyone and welcome to Developer Tea. My name is Jonathan Cottrell and today I have the pleasure of interviewing Andrea Goulet. Andrea is the CEO of Corgi Bytes. Corgi Bytes 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 makers versus minders 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, DigitalOcean is a fantastic solution to that problem. Both Andrea and I have used DigitalOcean. We talk a little bit about DigitalOcean later on in the episode. But for now, I want to go ahead and get straight into the interview with Andrea Goulet. Andrea Goulet. Thanks so much for coming on the show, Andrea. Thank you. I'm excited to talk to you about makers versus minders. 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 Bytes. Yeah, so I'm the CEO. So I'm in charge of really maintaining the vision. You know, 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, you know, has magic fingers and 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... 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, they all need to talk to each other. And, you know, 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, you know, 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 a, you know, kind of a freak accident and he really was the only developer on earth that enjoyed refactoring. Because most developers 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, it is. So we found that developers, really, 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, you know, there's the development of a product, then you introduce it to the market. So you're kind of building MVPs and then, you know, kind of getting some real quick feedback. Those are the types of developers that we traditionally think of. But there's products that then after they've been introduced, you maintain them. And so, you know, there's a lot of people who are kind of like, you know, you're going to have to keep doing the new stuff. 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, the development and introduction, there's the makers. And you see this all the time. Like there's maker fairs and maker fests and make magazine. They're the people who craft new things, right? They take some raw materials and they put it together. And, you know, 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 like real rush from seeing the thing. And then usually, it's like, okay, I know it's duct tape and prototype, but, you know, 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, you know, with that 80-20 rule, you know, the last 20% of the project ends up taking 80% of the time sometimes because there's a lot that goes on. There's a lot that goes on. There's a lot that goes on. There's a lot that goes on. There's a lot that goes on. There's a lot that goes on in that polishing phase. And I think that's part of the reason why developers, well, a lot of developers tend to, you know, think that the maker phase is the fun part. It's 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, in 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, you know, 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, or 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, it's not that I couldn't, and it's not that I didn't know how, it was, it's 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, Definitely. 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, 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, and those small wins over time. It's, it's a fun, fun environment to work in, even though it sounds boring. Well, as a developer, I think that's, that's an interesting, like, distinction to make, right? Because, maker versus mender, this is a, 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%, 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 mender, 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 I might, you know, is there something that I can fork off of 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, 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, 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, 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, I don't want all the drama. I really like it when I can keep things very controlled. Those are usually some signs that, 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, 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, it, there is a negative perspective of, you know, legacy code is almost a curse word in, 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 were listening to this show right now, and you have always wondered why people hate legacy code so much, you could be a mender. It could be that you are cut out to, 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. And 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, 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, you have a legacy code base. Like an existing code base is something that is legacy. Yeah. 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, 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, you know, 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. It's 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 a sudden becomes a lot more important. You know, how do I make it so that, you know, I'm, I'm running things and my technical debt isn't slowing me down from feature development. We see that. So we'll, 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, the architecture, 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 love the schools and your family's there. And now it's like, well, we've got, you know, new issues that we're not going to be able to deal with. And so, we need to compensate for it. So you might build an addition or you might, you know, renovate it or something like that. It's, 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 you hear that developers will always advocate for a complete rewrite. And I don't know that that's always the case. I think sometimes that may just be the loudest people. Yeah. 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 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. So 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, uh, uh, 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. And so I feel like that's a pretty good, pretty good allegory for, uh, 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, is like, when do you remodel? Cause 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 got and start over. We've totally advocated for that, right? It's, 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, 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, um, to go ahead and remodel because there's likely going to be significant cost savings. Sure. Yeah. Uh, so I want to talk about today's sponsor with you, Andrea. Um, yeah. And you've used digital ocean before. Yeah. What, what did you, what kind of projects did you use digital ocean with? Yeah. So, you know, 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, 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 too, is that just knowing that the data sits on an SSD, that's really, really good too. So yeah, it's fast. There's a significant amount of, uh, of bandwidth, uh, even on the low tier, uh, of what they offer. And I think there, I mean, it's just a great service and they are a sponsor of the show, but I would probably talk positively just as much about them if they weren't. Uh, so it's a great service, digital ocean.com. And actually, we have a code in the, in the show notes that you can find. It's the code is developer T 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 bites. And I think Andrea, you have a slide deck that I can put in those show notes, correct? Yeah, absolutely. So some more information about this, this idea between maker and mender, uh, will be in the show notes as well. Thank you again 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, you know, refactoring and making your code, uh, ready to be extensible and that kind of stuff. I, I really think that makers can start by building sustainably a little bit better than we currently do on the whole. Uh, 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, is huge. So, um, Arlo Belshi, who's a developer over at Microsoft, he has a great, great article on how naming is a process. And so when you're talking about naming variables, naming functions, things like that, uh, I really, really like kind of the approach that he takes when it comes to naming variables. Cause 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 should, 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, but in terms of what the code base does, um, 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, 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, um, you know, that might be a good sign that, that you need to write a method for it. And, you know, so, um, so spending some time there just to think, I think, you know, it's common things like the DRY principles, the 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, 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 this stuff. But in the, in the longterm, um, you know, a lot of duplication, a lot of complexity, um, that really, really bogs down your system. It's like swiping that credit card of, of technical debt. Absolutely. Yeah. I mean, just building sustainable software. We talked about this on the show in many different formats. Uh, I talk about the DRY principle. I also talk about when to break the DRY principle. Um, there are, there are so many different things that you can learn to be a better software developer. Um, uh, even in the maker phase to hand this 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, you know, being able to refactor things, being able to make code clear and extensible and flexible. All of those things seem to be, you know, the anti-debt, if you want to call it that. Yeah. And if, um, there's a really great video by a friend of mine, Llewellyn Falco, um, and, um, and also Woody, Zuel on practical refactoring. And it's a two hour video. So if you're interested in kind of learning more about like specifically, if you encounter some of these things, what are some really good tips and techniques? Um, that's a really, really fantastic resource to, to look at. Um, and it's a YouTube video. So that's, 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. Um, but there are definitely a ton of, of books out there as well on refactoring, but, but I really liked the video with Llewellyn put together too. Yeah. Yeah. Refactoring is, 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, you know, that's what we're all trying to do together. But this idea of maker versus mender allows you to kind of, you know, shift in it. And it's possible that there are developers out there who have, you know, 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. Uh, and, and there's nothing wrong with that either. The kind of like split personality developer or something. Uh, I find myself the same way when it comes to extroversion and introversion. Um, my wife and I talk about this all the time. Um, I have this extrovert side and this introvert side. There's nothing wrong with having a maker side and a mender side. Of course, you know, there are a, a set of skills that you need to have really homed in to be a good one of either of those things. Um, 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, 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, I'm interested to hear how you guys handle it. Uh, 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, the way on our website, it says any flame, any framework, any platform, any language. And we worked together for about five years before I actually got into the business. And I definitely 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 count we 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, the types of people that, that we look at. So some examples of, 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. Um, but it's, it's kind of like, 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, um, 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, 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, this looks very similar to C sharp, but they've done these things differently. Um, and I can understand why. So, so being able to kind of hone in really quickly. So, yeah, so that's, that's kind of where we said any framework, any platform, any language. And the other thing too, was 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, 10 years ago, it was how do I build these apps? And now the, 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. It's 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. 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, the second question I asked, which is what kinds of technologies do you think are suited for vendors to learn? An add on to that is when you are looking to hire, uh, a developer, is there any kind of like base knowledge things that you look for? Uh, what I'm hearing is you want people to understand how APIs work, maybe some API standard ways of doing things, but is, is there anything else that you look for in a developer to be a mender 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, um, what we like to see is kind of, um, big paradigm, time shifts across a 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 they'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 their 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 yeah, it kind of was a best practice, but maybe isn't right now. So it's that feeling of like, always wanting to stay, 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. Uh, maybe, maybe you're an expert in, you know, building APIs in general. Maybe you're an expert on, uh, 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, is 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, uh, over a period of time to really become an expert. And so to be a good mender, 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. Mm-hmm. Yeah. And it's understanding to, you know, what are the benefits? Um, 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. Um, you know, let me go, like there's a great tool. Uh, I don't know if they have go or Swift or rust on there, but, um, 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, um, 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. So 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, to watch, there's a Ted talk by, uh, 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 that it's, 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 just 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 developers 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. We, 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, I totally advocate for this position of neuroplasticity and constantly learning and constantly adding to, you know, that, 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, 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. And, and so that's, that's the, that's the key. 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, I'll 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, and don't quote me. Well, do quote me on this. I say, 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, all of my guests here on Developer Tea, what do you wish more people would ask you about? Hmm. This one's always a hard one. Can, can I tell you what I wish people didn't ask me? Sure. That, that'll work. I wish people stopped, asking me if I know how to code. I almost asked you if you are an engineer of, of some sort. Yeah. I get asked that all the time. So, you know, I, I look like your typical marketing girl, right? Like, I'm perky and I smile and, you know, I, I do come from a marketing background. And, you know, Scott, dark rim glasses, beard, like he kind of fits the stereotype of a developer. 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? It's, it, it makes me feel like, you know, am I not good enough? Is my code? It's like a test, right? And so, so I actually got. Do you really know what you're talking about? Yeah. Yeah. So I actually got a JavaScript tattoo, a function, uh, 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, am I really a developer? Like I've been doing this for eight years, right? And I'm, I'm constantly go, I read a lot more code and I'm, 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, where the problem is? So I do a lot of that. Um, you know, but, but I write, I write my own code and it's pretty good, I think. Well, you've been writing code for, for eight years, you've said? Yeah. I mean, yeah. You write code. But, but every, yeah. So, 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 some, a certain way that they do, or, or don't write code because it's a skill just like being able to, um, you know, do a podcast or write an English paper or form a hypothesis or, you know, like it's, it's, 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, 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, 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, uh, 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, uh, 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, uh, and really just get rid of them. Yeah. Yeah. It's not worth it. 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 dev conf and I'm not going to try to summarize him because I'm going to, I'm going to butcher it and, uh, he would hear it and probably laugh at me, but, um, definitely go and listen to his talk if it is online. And if not, ask somebody who went, cause 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, you know, people asking Andrea and people like Andrea, do you actually code? You don't seem like somebody who that's, that's such crap. Like stop doing that. Just diversity in general is getting a lot better because I would attend, you know, like Ruby conferences, you know, you know, six, seven years ago and I was one of maybe three women in the room. Yeah. Um, 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, um, but in general now I'm seeing, you know, it's probably 10, 20% women, which, you know, it's, that's a lot of growth in just, you know, kind of five years. So I, I see a good trend and I just hope it continues. Yeah. And in fact, at CSS dev comp, they had a, a blind review process for, uh, talk submissions. And it turns out actually about half of the talks were by women. And it was great. It was, I mean, diversity was definitely, uh, uh, visible at that conference more than I have seen in the industry in large in a while. Yep. And 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 mender. Uh, where can people find you online? They can find out more at corgi bites.com. Perfect. Thank you so much. All right. Thank you so much for listening to today's episode of developer T. 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, to today's sponsor, digital ocean.com. Once again, make sure you go and check out the show notes at spec. Dot 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 T, 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. Bye. Bye.