This week, we sit down with Kent C. Dodds to talk about learning and teaching code in public.
Over the next couple of episodes of this show, we're talking about learning and teaching in public. Today, we sit down with Kent C. Dodds. Kent has created some of the most important teaching materials for React developers at epicreact.dev.
In this part 1 with Kent, we talk about the roots of why Kent cares so much about teaching.
Thank you to long time sponsor and friends of the show Linode for sponsoring today's episode!
Simplify your cloud infrastructure with Linode’s Linux virtual machines and develop, deploy, and scale your modern applications faster and easier.
Listeners of Developer Tea can now enjoy $100 in free credit! You can find all the details at linode.com/developertea.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Over the next couple of episodes of this show, we're going to be talking to two guests. Both are totally dedicated to learning and teaching in public about code. Today's guest is Kent C. Dodds. Kent has created some of the most important teaching material that I've used for React developers. You can find that at epicreact.dev. Kent also shares a lot of his knowledge totally free. He also is a lifelong teacher. We're going to talk about the roots of why Kent cares so much about teaching in today's episode. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Let's get straight into the first part of my interview with Kent C. Dodds. Kent, welcome to React. Thank you, Developer Tea. Thank you so much for coming on the show. Thank you. I'm just so pleased to be here. Well, I want to first start out with a huge thank you because the work that you've done has influenced my career heavily. JavaScript testing, for example, I've learned most of what I know about JavaScript testing from you. Having come from kind of a Ruby on Rails background, when I was using just the jQuery and manipulating the DOM back in the day for fun, and then realizing... Wait a second. We've got to build the entire application on the front end now. I wanted to bring testing, but I didn't really understand it fully, and you helped me understand it. So thank you for that. I'm so glad. It's validating to hear that the work that I've put in has helped somebody out. So that's good. Well, I want to talk to you about that in today's episode because I've heard you talk about this, for example, on React podcast and Michael Jantz podcast. You talk about kind of what you believe your best offering is to the world to make it a better place. And the way that you talk about it, it made me think that you've really put some thought into this. This wasn't accidental. It seems like you've... In my mind, I'm thinking like you went on a retreat and tried to figure out what do you want to do with your life. How did you arrive at this idea? And to be clear, you can use your own words. I'm not the first to explain it, but from what I understand, you feel like your best contribution to the world is to be a teacher. I'm interested in how you arrived at that conclusion. Yeah, that's a very thoughtful question. I've always been one to share what I know. I'm a very enthusiastic person. And when I'm excited about something, then I like to share that with other people and try to get other people as excited about it as I am. It's kind of funny. I'm relentless in that where regardless of whether they're receptive to that, I just seem to not care. I'll just be excited about it. I like to share the things that I find interesting. And that typically naturally comes out of trying to explain something to somebody. And so I'm really excited about testing. And so I made testingjavascript.com as a great way to test. And that's... And show people how to test. And I made epicreact.dev so that I could teach people how to... This thing that I'm really excited about, React, and how to use that effectively. So, yeah, it's always really been kind of part of my personality to share what I'm excited about. And typically the way that you share something is by teaching in some form. And so, yeah, like speaking in front of crowds has been something that I've done since I was like a kid at church. And, you know, when I started doing software, it was just a natural thing for me to start speaking at meetups and hosting workshops and things like that. And, you know, going to conferences to speak at conferences and things. And I think I realized after a while that I could build products and I could impact a lot of people and make a positive impact in the world. But I just naturally spent more of myself... My time trying to teach the things that I was learning as I was building the products to my fellow coworkers. And I realized that if I can make a big impact by writing good software, I could make a better impact or an even bigger impact by teaching other people to write better software faster. Because then they can take the things that I've taught them and go off and make their corner of the world a better place. And so that's kind of where I've landed and why I've gone full time as a teacher. Because I've realized that... I can make the best positive impact on the world by creating software. And I can do that best by actually teaching other people to create software better. It's interesting because it's very similar to the reason why I decided to continue this podcast. You know, I've gone through this for many years. And at some point, I kind of came to a crossroads where I was like, okay, you know, this is something that's taking a good amount of my time. And it's worth it. But I want to make sure... I want to make sure that it's, you know, not only is it worth it from like a financial standpoint, but also that it's doing something that I care about doing in the world on my, you know, kind of as my, whatever you want to call it, your legacy, your purpose. Something that is deeper than just being successful by some external metric. There's some internal satisfaction. And I arrived at something very similar to what you're saying, that software is incredibly important. It's shaping the world. Perhaps more than... Maybe more than any other type of artifact. Right? It's a very impactful thing. And it's impactful both internally for software engineers, but also externally for the rest of the world. The people who are using the software and the gradient of people in between. The people who are kind of casual software engineers, if you're sure that's a thing, right? And so I came to the same conclusion that one of the most important things I can do is try to talk to those people. Talk to the people who are interested in it or even who are feeling like they might be interested in it. And that's actually another piece of your story that I want to ask you about. You're interested in teaching, but there has to be a gap at one point where you... It's kind of this knowledge gap where you're still learning yourself. And I'm curious about how you think about teaching as a beginner. Versus teaching in later stages as a more experienced engineer, for example. What are the differences there? And when did you feel qualified? That's a great... Also a very insightful question. And it's a question that I get from beginners a lot. Because I'm always telling people that you need to teach to solidify the things that you've learned. You don't really understand something until you've started teaching. And so the natural... The question for beginners is to say, well, somebody already wrote a blog post about everything that I know. Like the content for everything that's in my brain is already on the internet. So how could I possibly contribute anything? And the metaphor that I normally use to talk about this is, have you ever seen a Burger King and a McDonald's side by side on the road? Or there's even like... A place in Texas where they have a corner. Four corners on the street. And three of those corners has a Starbucks. So there's three Starbucks on the same corner in some place in Texas. So why do they do that? Didn't they already solve this problem? The problem of I need a coffee. Or the problem of I need a burger. They solved it already. So why would they do something like that? And the reason is because there's enough of a market for the different things. That these have to offer. I'm not so sure about the Starbucks thing. That seems a little gratuitous. But at least for the different flavors of burger, it makes total sense. It's a little bit different because we've got the internet. And so I don't have to... With brick and mortar stores, you put up a bunch of McDonald's. Because one's closer than the other or whatever. But with the internet, I have access to everything that's public everywhere. But that's not... Really what makes one person go from one to another. It's not just the accessibility or relative accessibility of content. It is how accessible is that content to that individual. Everybody is going to teach this content in a different way. But then even more than that, even if nobody reads your content, you wrote the content. And there's a lot of value out of doing that. And maybe it's not writing. Maybe you're doing a blog. But maybe you're doing... YouTube videos or giving talks or whatever. Making a workshop or something. But the idea is the process of that creation is how you're going to solidify what you're trying to learn. And so it really is irrelevant whether people consume your content. It's the production is where the value comes in. Producing that content is where you're going to get the value out of it. So whether you're a beginner or super experienced, you need to produce the content to really solidify your understanding of it. I'm going to play the role of a skeptic and ask why. Why does this help for me to say, well, I know this already. I can show you I know it. I'm using it in this project over here. Why does teaching it help me become any better, any more thorough of my knowledge here? And I have a theory as to why, but I'm going to keep my skeptic hat on and let you answer first. Yeah, yeah. The skeptic actually, is proving my point. Um, so because of that, that pushback, that, that question that you're giving me, it's causing me to be more introspective on why I hold the opinion that I do. And so like you may think that you, you say, okay, I'm, I'm using, uh, this CSS and JS library. I'm using emotion. Um, and I like it better than styled components or I like it better than using CSS monitors, which is regular CSS. And so like you've just developed this opinion, naturally. Um, but then somebody is going to come and ask you, like if you try to teach it, somebody is going to come and ask you, okay, so why, why do you prefer it this way? And it triggers this response in, in yourself of introspection where you're thinking, you know what? I, I really need to come up with a reasonable argument for the way that I feel. Uh, and, and eventually you may end up changing your opinion or, or solidifying your opinion further. Um, but it, it does cause you to, you know, dig into the implementation. Like you have some assumptions like, oh, well, CSS and JS is faster, um, because of X, Y, and Z. Like, well, we can do code splitting or whatever, but you have to dive in to make sure that you're right. Um, and, and if just spout out, um, falsehoods or, or things you don't know, then like you probably know that you're doing that and you shouldn't, uh, you shouldn't just spout out falsehoods. Um, and so if you're not certain of something, then you're going to go do some additional research. And so it's the questions that people ask you or the questions you think they might ask you is what, um, makes teaching such a, a solidifier of knowledge. Yeah. Yeah. That last part is actually was, was my theory, uh, of why it, why it works so well is you kind of assume the role of the person who's trying to, uh, challenge what, you know? So the questions of why, why is it that way? You know, you may not have asked that to begin with. Uh, you may not even consider for a second time, you know, why is it that I like this thing? It just, maybe it's in the zeitgeist. Maybe you heard it from somebody that you trust. You know, there's all of these on their face valid reasons, but they're not mechanistically valid. You haven't really investigated to determine that. And you end up kind of trusting the authority or whatever thing that you're trusting. And, uh, if you, if you go to teach it, you can't teach it based on, on those reasons. You have to teach it based on something else. Yes. Yeah. You have to try and take your, uh, subjective feelings about the thing, which are very possibly correct, um, but also possibly wrong. And you have to objectify them as much as you can, um, and, and back them up with, uh, with true evidence. Like another thing, as I'm learning to teach react, I'm, um, diving into, you know, APIs that react exposes and I'm thinking, okay, well, I need to teach them how to use this particular tool for optimizing performance of their component. Uh, and so, you know, react.memo will memoize the thing. Well, Oh, I'm going to dive into this, learn as much as I can about it. And I end up learning stuff that I've, I never actually put into practice myself because I never really needed it. So like, you may think that you have a really good understanding of the tools that you're using, but, um, there are use cases that your tool support that you may never have had. And so you never really needed to dive into those, or maybe you have the use case and you just don't realize that they, um, they support that tool. Um, you can't get that out of the box. And so you're doing this work around or whatever. And so as you're going through preparing to teach this stuff, you start exploring things deeper than you did when you were actually just building stuff. And, uh, you'll come to realize that, Oh, there's actually a second argument I can pass to react on memo. And that's called the comparator function. Now I have to understand that so I can go teach that, or at least address questions that people ask me. So I can say, Hey, I never really needed this. Here's what it does, you know, whatever, whatever it is that you're trying to do. And so you can start to see, but, um, as you're preparing that information that you're trying to share with other people, it, um, forces you to dive a little deeper than you may have when you were actually building stuff. Today's episode is sponsored by Linode with Linode. You can simplify your infrastructure and cut your cloud bills in half with their virtual machines. You can develop, deploy and scale your own modern applications faster and easier. Whether you're developing a personal project or you're managing larger workloads, you deserve simple, affordable, cloud computing solutions. You can get started on Linode today with a hundred dollars in free credit. A hundred dollars goes a long way on Linode, by the way, a hundred dollars in free credit for listeners of developer T you can find all the details at lino.com slash developer team. Linode has data centers around the world with the same simple and consistent pricing, regardless of your location, you can choose the data center nearest to you, or you can choose a data center that is nearest to your customers or your users. You also receive 24, seven 365 human support. That's all the time. In other words, you're always going to have top level support. You're going to have the same support as someone who has a top level kind of, uh, the biggest account that Linode has. There's no tears. There's no human support tears. Everybody gets that high level support from Linode. No handoffs, regardless of your plan size, you can choose shared and dedicated compute instances, or you can use your a hundred dollars, including your cloud computing services. You can also use your cloud computing services. You can also use your cloud computing services. On S3, compatible object storage, managed Kubernetes and more. If it runs on Linux, it just so happens that it runs on Linode. Head over to linode.com slash developer T and click create free account. That's a button. Click the create free account button to get started and get that a hundred dollars of credit. Thanks again to Linode for sponsoring today's episode of developer T. I think we're, it's almost religiously accepted. That problems are our best teachers as engineers. And often we do learn so much from the practical problems that we, that we face. But I think it was, of course it was a Paul Graham essay on Lisp. He talked about why Lisp was a more powerful language. Of course, he's very opinionated because he, but he says it, it in, it empowers something that other languages don't at a fundamental level. In the sense that, it's not that other languages do it worse. It's that they don't do it at all. And so it's this new tool that you wouldn't even know that you could use if you were using other languages, but if you're using Lisp, it's just kind of secondhand or second nature rather. And it's very interesting because you wouldn't know that just from solving a problem. You could probably solve the same problem with two totally different tool sets and imagine that you've learned the same thing, but you may not have learned the same thing. And it seems like there is some other approach, right? To go and just look at the tool set itself as kind of an observational exercise rather than saying, okay, I'm going to go and pick up the tool that I need when I need it. Yeah. And you know, I don't want to downplay the benefit of practicality and actually building stuff. I have this talk that I actually just gave and I might be on YouTube by now. I'm not sure it was at a react summit and it's called consume, build, teach. And that is my process for learning anything. So you like you, the basic idea is you consume information so that you know what's available, what's possible, what tools are there and get a basic understanding of the problems that they solve. And then you go and build something so that you can face problems and use these tools to solve those problems and get an idea of, you know, how these tools work. And then you go and teach the things that you learned, which will trigger you diving deeper into those tools than you may have when you were starting. Solving the problem. And that's, that's really the recipe for true learning. Yeah. That's, it's interesting because there's this, obviously there's this connected relationship between teaching and learning. And you certainly are, seem to be a scholar on the subject of learning and teaching. So I'm interested to know, you know, what is one of the things that people most often get wrong about the process of learning itself? Um, not, not learning anything specific, but the process of learning. Ooh. So, um, I, I have a couple of thoughts about this, but they, they basically boil down to, um, thinking that learning is a passive experience. I guess it, people who get stuck in the consumption side of the equation, um, so they, they consume things. They never really build anything. And if they do, they, they don't teach, um, the things that they've learned. And so, um, without all, all, all, all of those steps, you're not really going to get a solid understanding of what you've, of the information that you have in your head. Um, so I see this very often where people will sit back on their, their recliner, uh, flip on the Chromecast and watch a, a, you know, four hour or maybe a 40 hour course on Udemy or something. And, um, by the end of it, they, they think that they've learned what they watch, but they really didn't. Um, you, you won't have that information at hand. Now, um, there is benefit to doing this. Like you, you will know that, Oh, I remember that this was a problem that they had in that video and they used something to solve it. And it was like something like this. So then you can go reference it later. So like, there's something happening there, but it's, it's not learning. Um, it's just cataloging, uh, of information. Um, and, and our brains are pretty, um, they're pretty amazing, but, um, they're also really great at garbage collection. And so if you don't, uh, try to reference, uh, that catalog, um, item, then you're going to forget it in the future. Um, not too distant future anyway. So it's not really true learning. And so, yeah, just sitting back and passively watching, um, material or whatever, reading blog posts. Another thing that I see that's related to this is tutorial purgatory, where you just, you, you buy a course or you, uh, find a blog post and you go through the tutorial, you do exactly what they did. And you just keep doing this over and over again. And you never actually build something of your own. This happens a lot too. And you, you will not learn stuff, just rehashing what other people are doing. and so, and this is actually something that I, I specifically combat in epic react. Dev, um, where like most teaching material, actually, I'll, I'll stop right there and I can talk about my strategy on epic react. Dev. Uh, but I'll, I'll go ahead and stop. Cause I can talk a lot. Well, I, I do want to get into it and, and, uh, and perhaps this will, will actually open us, open us up into that. But I want to ask you a question, uh, that, that I like to ask all my guests. Um, what do you wish more people would ask you about? What is something you wish more people would ask you about? Huh? Um, I don't know. Uh, I, I guess I get so many questions, like a ridiculous amount of questions, um, because I, I try to be really accessible to people. I, I, in fact, I've started doing office hours. So twice every week, I'll, I'll give an hour, um, of my time to just answer people's questions. And that way I can kind of, um, batch answer a bunch of things. Um, so I get, I get questions about a lot of stuff. Yeah. I, I don't know. I, I think, see, like stuff that comes to mind is like, how can I help you with what you're doing? But I, I actually get that a lot. And I, I, it's hard to, uh, to accept or like, I always accept people's help, but, um, I'll just, this is a bit tangential, but I'll, I'll just mention it. Cause I think there are some, um, interesting takeaways. Um, so when somebody comes to me and says, Hey, I want to help you do something. Uh, I just want to help you with your open source or, or with your blog or something. And so I'll say, okay, well, here's a thing that I want done. You know, I, I need X, X finished. And so they'll start working on it, but they lose steam. And the reason that you lose steam on something like that is because you're not really actually invested in, in this. Um, you know, this, this does, it does work out sometimes, but like, I need this pull request. Yeah. You know, I, I need this thing worked on or it doesn't end up playing out very well. Most of the time, because, um, it's not your own problem that you're solving. And I realized that was not at all what you were asking about, but that was just something that came to mind. Like, don't try to solve other people's problems. Try to solve your own problems. And if you don't think you have problems, you do, you need to hold your breath a little bit longer. And you'll, you'll find out that you do have a problem, right? Yeah. Yeah. You have problems. Um, and, uh, just try asking other people for the problems that they have and trying to solve their, I mean, like that's what building a product is right. And making a startup, but, but it, you're much more effective when you have, uh, you have felt the pain that you're trying to solve. So anyway, that's, that's not related. I'm not sure what, uh, what questions I want people to ask me about. It's a, it's a hard one to, it's a hard one to answer. Um, especially for someone like you, who you probably are getting a lot of questions about things that you do like to talk about and, and perhaps questions that you've answered a hundred times. I know you've mentioned this before, um, on, on react podcasts where you have kind of preformed answers in the, in the form of a blog post for these kinds of questions. Um, but, but the, the, I guess the underlying concept there is, you know, what is a topic that is really kind of, uh, that you have a lot of energy to talk about whenever it comes up. That's really kind of the, uh, the thrust of the question. Ooh. Yeah. Um, I, I don't know why, but testing is always something that gets me excited. I can, I can talk forever about testing. Um, I honestly, like, like I said, I don't know why I, I, it seems like such a dull topic, but I can talk about it forever. Um, I'm also like anything that's on epic react.dev, all, all of those workshops, I could talk about those for a long time. Uh, so react to something that gets me really excited. Yeah. I, I don't know. I, I mean, there's, there's non, tech things. I get really excited about the, the future of energy, um, you know, battery and, and stuff, um, solar. And, um, I, I'm super bullish on autonomous vehicles. I have a Tesla. It's amazing. You know, I, I could talk a little bit about, uh, um, artificial intelligence and its impact on, um, software. Um, I, I'm not super well versed in it, but it's a topic that gets me interested in, in kind of what our future looks like in the next 10, 10 years or so. Um, so yeah, those are a couple of things that I, I kind of enjoy talking about. Yeah. I think, uh, actually when, when you got your Tesla, I think you mentioned it on Twitter and it was around the same time that I got my Tesla. So you must've had some pretty similar experiences since then of, of, uh, of the, the kind of the process of acclimating to that kind of, uh, autonomous vehicle is, it is definitely an experience. Yeah. It changes you, man. Well, I do want to talk about, I do want to talk about testing and I want to talk about it. Maybe, uh, we can actually frame it in the lens of something like, uh, you know, the, uh, looking at Tesla, right. Um, obviously these are, you know, we're not talking about testing front end components necessarily with, with Tesla, but we can think about, you know, the, the importance of a test in terms of its, uh, of its consequence. I certainly hope that we have a lot of tests that are backing, uh, our, um, uh, our experience when we're, you know, turning on, uh, uh, the navigation mode on, on our Tesla's right. Because the consequences are huge there. But I'm curious about what you think about this. You know, how do you think about coverage? I know you have the testing trophy. It's something people can have. If they're listening to this, it probably know about, we can talk about that a little bit, but how do you think about the importance of coverage on, let's say an area of your code base that is, you know, dealing with trivial things, not so important versus areas that are much more important, like payment pathways and that kind of thing. Yeah. So the, I have a blog post about pretty much any subject you could ask me about testing. I have a lot of, um, I've written about this a lot. I need to write a book. Um, but, uh, my thoughts on testing coverage, um, are you, you framed it really well. Like not every line of code matters as much as the next. Um, so this line of code has something to do with the settings page, um, for admins only. Okay. So maybe that's important. Um, you know, that they can change their display name or something, um, that we, we want them to be able to do that. But then this other line of code over here is what controls, you know, the car's ability to turn left or, you know, like that's a pretty important line of code. Um, the problem with code coverage is that that metric doesn't give you any insight, right into how important that code is at all. It's just a metric. So you can have a hundred percent code coverage on that settings page and 0% code coverage on self-driving. And, um, that's not a good thing. So I don't really, I don't, um, take too much stock in the, uh, coverage report itself. Now our, our tools do have the ability to say, okay, like this area of the code base needs to have this percent of coverage in this area of the code base. Does we don't care as much. So I, I would recommend, I would recommend configuring things that way. Um, but like, uh, the, the big, biggest challenge is you, you never really get a sense out of these automated tools, um, of like how confident you actually are that you can ship your, ship your software. Even if you were to have a hundred percent code coverage, that's not going to tell you that you're confident in shipping your software either. Um, and so what I typically try to think about when I'm testing a code base is how do I, um, think about the use cases that I support and how much of a use case coverage do I have? Uh, and that's what I, I focus on when I'm thinking about testing a code base. And the only use for the code coverage report is just to remind me of use cases that I'm not, uh, I'm not considering in my tests yet. Um, so I don't look at code coverage and see lines of code. I look at code coverage and interpret that to be use cases that I'm missing. And that's what I try to cover. It's, it's impossible to really quantify, but that's what I think about when I'm, I'm testing. Yeah. So I think that's a really good point. And I think that's a really good point. And I think that's a really good point. Um, I think that's a really good point. Um, I think that's a really good point. Um, I think that's a really good point. Yeah. It's, it's tough because, you know, it's, we don't have ways of, I'm sure there are ways there's probably entire libraries to do this, but marking, you know, the, the severity level of a particular, let's say method, right. How do you, how do you know that that's a really important one and that it should be covered twice, right? That's, that's a difficult thing. Um, and you kind of have to have experience with the code base in the average code base. Um, like I said, I do think they probably have some kind of like metaverse, um, metaverse, meta marker kind of decorators or something like that to say, Hey, this, this particular method, this one's really, you know, on the critical pathway. Don't mess with this unless you really know what you're doing or, uh, unless you are, uh, certainly covering it well with, with tests. Yeah. So that, so that's an interesting problem to solve. Uh, I'm, I'm interested to know also, you know, if, if we're talking about testing and, uh, we're talking about kind of practical building of software. It's very, I would say it's, it's kind of easy to come up with a project, right? Like, uh, like you said, in, in tutorial, uh, uh, what did you call it? Tutorial purgatory. Yeah. Um, it's easy to come up with a kind of a pet project to write for, to, for a tutorial. And it's very clear what the test should be. You know, you can, you can see the use cases. It's all on a perfect spreadsheet, you know, that's easy. But when it comes to practical problems where there's crossover or there's dependencies, outside of your project, or, you know, there's, there's things that are outside of your control. Uh, maybe there's some legacy code you're dealing with, you know, how do you navigate those kinds of problems? Do you have any kind of mental models for decision-making in those areas when things get more complicated than just tutorial code? Yeah. And this is one of the reasons why a tutorial purgatory is such a problem because you don't face unexpected problems often. Like you, you will sometimes, but, um, everything's really well laid out for you and you typically don't have to make these kinds of decisions. Um, so when I'm thinking about adding tests to an existing code base or something, I actually do have a blog post. I think that's titled that. Um, but, uh, I, I basically, I, I kind of take a survey of the application itself. And I think about what use cases are really important that I should not break. So I, maybe it's an e-commerce site. I really want to make sure that checkout button works. Now you wouldn't be able to, uh, you know, enter in your credit card and, and, um, do the checkout, you know, enter in your home address and everything, do the checkout every single time you want to release. Um, you know, that, that, uh, could cost a lot if you're like selling boats or something. So, um, you, you will need to set up some tooling around that to make sure you're not actually making a purchase of a boat. And, and there are strategies, that I can teach you on testing javascript.com and how to skip that portion. Uh, so you're not actually buying boats every time, but, um, that, uh, that's where I start. And when I'm thinking about adding tests to a code base is like, what part of this code base would be really, really bad if it broke. And that's where I'm going to start. And, and if you've already feel really confident, um, with your automated test suite that you're covering those use cases, then you can move down to the next year of like, this would be pretty inconvenience. Um, I would have to get up in the middle of the night if there was a problem with this, or, or maybe this would be the first thing I'd had to fix in the morning or whatever. Um, you just, you really prioritize testing, just like you do prioritizing writing any of your software. You say I could either write this feature, um, or I could write this test, uh, for an existing feature, which one is more important right now? Well, I mean, customers want the feature, but, uh, customers also don't want things to break. So, um, you, you do a risk analysis and then you just, you make your PR you prioritize things. I actually have a blog post about that too. Um, so yeah. A huge thank you to Kent C. Dodds for joining me on today's episode and the next episode of developer T. Kent is an excellent teacher. I encourage you to go and check out the work that he's doing, especially Epic react. If you are interested in being a react developer, head over to epic react.dev. Thank you to today's sponsor, Lynn, out. When it is going to give you a hundred dollars in credit as a listener of this show for creating a free account, head over to Leno dot com slash developer T to get started with that a hundred dollars in credit today. Thanks so much for listening to this episode of developer T this episode and every other episode of this show up to this point is available on spec. Dot. FM head over to spec. Dot. FM to find show notes and other shows that you may enjoy as an engineer. This show would not be possible without you as the listeners sharing it with other people that you know will appreciate the show. There are a lot of places you can share this. Of course, you can share it directly with people, you know, or you can broadcast it out on something like Twitter. All of that sharing counts. It's so important that we get the word out about developer T so we can continue to reach engineers that care about these ideas that actually want to grow in their careers. And you are, the way that we do that. So thank you so much for sharing this show. This episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.