Teaching in Public w/ Kent C. Dodds (part 2)
Published 12/2/2020
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 2 with Kent, we talk about building a teaching platform and the importance of giving away most of your knowledge for free.
🌎 Kent on the Web
✨ Sponsor: New Relic
Thank you to New Relic for sponsoring today's episode!
Make managing and analysis of complex digital architectures work for you. Check them out at NewRelic.com to become a full access user with 100GB per month totally free.
📮 Ask a Question
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.
🧡 Leave a Review
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.
Transcript (Generated by OpenAI Whisper)
That's where I start when I'm thinking about adding tests to a code base. It's 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 if you already feel really confident with your automated test suite that you're covering those use cases, then you can move down to the next tier of like, this would be pretty inconvenient. I would have to get up in the middle of the night if there was a problem with this. Or maybe this would be the first thing I'd have to fix in the morning or whatever. Or you just, you really prioritize testing just like you do prioritizing writing any of your software. You say, I could either write this feature or I could write this test for an existing feature. Which one is more important right now? Well, I mean, customers want the feature, but customers also don't want things to break. So you do a risk analysis and then you just make, you prioritize things. I actually have a blog post about that too. So, yeah. You just heard the voice of Kent Dodds. Kent C. Dodds is on our show again for the second day, for the second episode in a row. Of course, this is the second part of my interview with Kent. Kent is a lifelong teacher. He built EpicReact.dev. You probably know him from a hundred different places. You've probably read one of his blog posts before because he's written a blog post about, seemingly, everything. I hope you enjoy this episode. But first, if you haven't listened to the first part, you probably should go back and listen to that. You might be a little bit confused if you don't. My name is Jonathan Guttrell. You're listening to Developer Tea. And my goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And on today's episode, we are finishing up our interview with Kent C. Dodds. Let's get straight into the interview with Kent. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. It's never easy. To sum it up on, in your blog post, on this podcast, here's how to make all testing decisions forever. It's just not that easy. Even, I've certainly worked in codebases that had over 100% coverage. Don't ask me how it's possible. And you still have things at break, right? Even when you're covering things completely. Well, because coverage is not really, it's a meaningless metric if the code is wrong or if the tests are wrong. for that matter. So, uh, so testing is a hard problem and perhaps one of the reasons why it's, you know, it's something that we can always be refining and always be getting better at. There's not really an end to that discussion. So I really appreciate you kind of investing in that, in that topic discussion. I'm interested in, I'm going to kind of shift gears a little bit here. What is something that you can look back on having learned, um, that, that shifted your way of thinking or, or was it kind of a, a moment, a kind of a colossal, you know, change perspective shift for you? And what was it that caused that moment to occur for you? Oh, um, when I started working with react, I had a moment like that before I was working with angular JS and, um, you know, templates, directives of all, you know, controllers, all of that. And I got really good at it. Um, I, I spent plenty of time, in the debugger within the angular JS code base. I even contributed to angular JS. So I, I was deep into that. I had a podcast. I, you know, I was teaching about it. Um, and angular two was coming around and I was teaching about angular two, um, before it was, uh, it was released during that, like two or three years, uh, that while we were waiting for that to happen. Um, and, uh, and then I tried out react and it just blew me away. I was so, I was just floored at what I could do with react and the, uh, the level of simplicity. Now it wasn't easy. Uh, simple is not easy. These are different words. Uh, go Google it. Um, simple, um, in this context and what it actually means is that it's like the opposite of complex complex is where things are, um, mingled together. This is like jQuery spaghetti code. You change one thing over here and something totally different changes or impacts something you weren't expecting. There are leaky abstractions. Uh, react just nailed the component model and that made a big impact on me. Now it was another year before I switched from angular JS to react. But from that day, I started writing all my angular like react. I would, so this, this is angular one, uh, angular JS. And, and, um, this was before they created the angular dot component thing that you could use. Um, but I started using directives like components because it, that, um, idea of a component model just really rang true, true for me. Can you, can you expand just a, just a little bit on, on what that means on the component model? How, how did that change what you were doing? Uh, with, you know, with angular, what, what would be a, an example of a change that that would have made in the way that you were writing that code? Yeah. So with, with angular, um, the kind of de facto standard way of doing things was if you wanted to take an element that you were rendering and enhance it with capabilities, you would, uh, create, uh, an element that you were rendering and enhance it with capabilities. You would, uh, create a component model that would be able to do that. And so that's what we're doing. You would create a directive that enhances that thing with capabilities and you would apply that to the element you're rendering. And then if you want to add another capability that like is a generic, uh, sort of thing, then you would make another directive and you'd apply it. And so this element would inherit all of these capabilities from the different directives that it was using. The component model, uh, is different rather than inheritance. You're talking about composition where you're taking a component that is responsible for a single thing. And you, you just render that one component. And if, if you want to enhance it, then you're going to share that logic with, um, with JavaScript. And that ends up working out really nicely. And especially now that we have hooks, that's really easy to do because you have this logic that you want to share. You make a custom hook out of it, and now you can compose those different custom hooks together to build these larger components. But the idea is that the component is entirely encapsulated. It's a black box to the outside world. And so you can put all of the junk and terrible code that you want to inside of this black box. And that the fact that that code is terrible is not going to impact the rest of your application because it all lives within side that black box. So, um, I mean, we could get really technical here, but I don't know if that's what the audience here wants. Um, but it makes a pretty significant impact on the way that you structure your applications when you're building a code. So, um, so that's, that's a really good point. Yeah. And then you have a component model like react. Yeah, that makes total sense. Um, and, and composition over inheritance is certainly something that we've talked about on the show. And what's interesting is, is that same concept is, it can be found in other languages, right? It's, it's kind of a shift that you were able to apply in this particular regard, but you can imagine this in a, like a backend lane, you know, Yeah. JavaScript backend now, uh, you could imagine this in like Ruby, uh, somebody using a composition rather than inheritance and it changing the way they think about code forever. Absolutely. Yeah. Composition, uh, over inheritance was, was the mind shift change for me in this case for sure. So, uh, another, yeah, just, uh, another big mind shift change was more career for me. And that was, um, when I realized how lucrative teaching can be. Um, because of the, the enormous impact that I can make with teaching and like getting really good at teaching and, uh, good enough that people are willing to pay you, um, for, for what you're teaching them. Uh, I didn't realize that could be like a, uh, something I could do full time. Um, and that it would be like a, a replacement for my, um, for my salary. So like the first part of that was the first course I made for egghead. Um, it, uh, it was about authentication with angular JS. And that first month I, I paid for my mortgage just with that, that paycheck. Uh, I don't know if that's how that works these days. I think new egghead instructors, I don't think make that much on their first course now, but back then, um, we, that's, that's what happened. And it just like blew me away that I could say, Oh, I guess I, if I keep this up, I don't need a mortgage. Like, yeah, that's just not a thing. And then the second time that I, got blown away by this was when I, uh, created testing JavaScript, uh, which did just super, super well. And I realized I didn't need my salary anymore and I could go full time teaching. Uh, and I didn't have to do all my teaching in the evenings, uh, you know, recording videos and stuff, um, after the kids go to bed and yeah, it just totally blew me away. So, uh, that was another like big paradigm shift for me was realizing that I could turn this side hustle. If I hustle really hard, I can turn the side hustle into a full-time thing. Yeah. And you know, it's, I know that a bunch of people who are listening to this right now are probably, uh, swapping from their podcast listener over to Chrome and Googling how to start teaching on the internet. Uh, so what advice would you have for people who just heard that and certainly, um, are, are inspired by that or, or are interested at least in, in kind of walking down that path or, or looking at it at least what, what would you tell them to look at? Well, I, I do have a blog post about, I have a post called how I teach. Um, and also another one about how I record screencasts. Um, but what I would suggest if you really want to like, so there, there's two things like there's how to, how do you teach and how do you get really good at teaching? And then there's, how do you, um, take your ability and actually monetize, monetize it in a way that is effective and you can actually, um, pay your mortgage mortgage or whatever you want to do, uh, get the freedom that you're looking for. So getting good at teaching, you just, you gotta do it a lot. Um, like there's just like software, uh, skills in general, there's no shortcut to getting good at this stuff. You just have to put in the time. And so, um, I would force myself into situations where I had to prepare content. I'd say, okay, I'm going to do the brown bag lunch, um, you know, training on X thing because I want to learn that thing. I don't know it yet, but I'm going to, um, and I will teach you what I learned. Um, you, you put yourself in those uncomfortable situations and all of a sudden you get, um, really good at preparing content. You schedule yourself to, you know, I, I wouldn't teach anything or, or volunteer to teach anything that I wasn't sure was possible. Like I wouldn't say I'm going to teach you how to use JavaScript to get to the moon like that. You know, I know that this is possible. I just don't know how to do it myself. So I'll, I'll volunteer to teach that and that will encourage me to learn it. So, uh, I, I proposed several talks, um, at conferences that were precisely motivated in that way. Um, and so, yeah, you just, do it a lot. And then as far as like making it something that you can actually sell and, um, you know, make money on it. A really important part of my strategy is to produce a ridiculous amount of high quality free content. And, um, this is, you know, you might call it content marketing or whatever you want to call it, but I, I have tons of blog posts. Um, all of my material is open source. Uh, I, I have my podcasts, I have, um, my, um, YouTube channel, just a silly amount of content, give people a reason to, uh, to trust you with their money. Um, and so then I, I just make premium content, um, that, uh, that I charge for and people are like, well, I mean, I've learned enough, uh, from this dude to pay him without getting anything in return. So I'm, yeah, heck yes, I'm going to do this. And so, yeah, just, uh, a long-term, uh, long-term, uh, long-term, uh, long-term, uh, long-term, uh, long-term, uh, a lot of free content to prove to people that, you know, what you're talking about, you know, your stuff. Uh, and then also you want to make sure that you have a mechanism for communicating with that audience. And so, uh, collecting emails, uh, early, like start, start your mailing list today. Uh, it's really easy to do. Um, I use convert kit and it's awesome. And, uh, yeah, just create value for people, give people a reason to follow you, give people a reason to, uh, to want. To know more, um, and do it for free. And then when it's time to ask them for money, uh, you can do that. Um, and I actually, I do have a blog post, uh, called, um, you know, getting noticed and widening your reach or something like that. Um, where I talked about this a little bit there too. Of course you have a blog post. Yeah. Um, yeah, that's, that's, that's, uh, that is all, it all makes sense. I mean, really what you're saying, uh, in large part is work hard. That's, that's a, that's a, that's a big component of this, right? There's no, but also I think that, you know, one of the most critical things that people, um, may not realize is that the credibility that you provide, uh, uh, is such an important part. And this is true, whether you're trying to sell a product online or if you're just trying to get a job, right. And you're, you're kind of selling yourself, uh, in either scenario to some degree. Right. So having some way of saying, Hey, look, here's my body of work, right. And whether that's valuable to you directly or valuable to you indirectly, in the sense that I I'm proving that I can do this thing that you're asking me to do on behalf of your company, putting that stuff out there is almost always a useful idea, right? So if you, there's probably a developer right now who's trying to decide, like, should I sell this or should I give it away? You're not going to lose, probably anything. If you choose to give it away, at least to begin with. Yes. Right. Probably not going to lose anything. If anything, there's a lot to gain from that. Now, if you were to do the mental calculus of, Oh, if I could sell it to a hundred people at a hundred dollars each, then I make X whatever. Yeah. But how do you quantify it over that long period of time? People getting value out of that indefinitely as a free resource. Yeah, absolutely. It's, it's so easy to get, wrapped in the whole, like, well, the market is tens of thousands or hundreds of thousands of people. If I charge them all a dollar, then yeah. But like, why are they going to give you a dollar? They're not going to give you a dollar. Right. Right. If they do, it's probably the only dollar they're ever going to give you. Right. Like you're not going to build, you know, the, the Kevin Kelly I'm sure you've heard of the thousand true fans and you're not going to build that. But I imagine, can you have people who, who have bought everything that you've put out and they're like ready for you to put anything out next and they're going to buy the next thing too. Yeah. Yeah. I do have those people for sure. And they're awesome. Love those people. And it's not because they're just like personal fans of you. I'm sure some of them maybe, but right. Exactly. Exactly. It makes total sense to me. Monitoring a complex digital architecture usually takes a dozen different tools. It's painful. Yeah. Troubleshooting. Just troubleshooting the simplest things might mean jumping between dozens of dashboards, trying to remember that login for that one service that you hardly ever use, but when you need it, you really need it. This is the picture of what it means to monitor a complex digital architecture, or at least it was because new relic wants to change that. And they've designed everything you need in three products. The first is a telemetry data platform. Which creates a fully manageable schema list time series database of all of your data from any source. The second is a full stack observability system for analyzing, visualizing, and troubleshooting your whole stack. And third is applied intelligence. This is where it all goes kind of to the next level. Applied intelligence seamlessly automates anomaly detection and incident intelligence correlation using AI and ML. And best of all, you can get live data from any source. So you can get all of this for free. There's no host space pricing and no constant upsell for more functionality with a hundred gigabytes a month to one full access user. Go and check it out. Head over to new relic.com. New relic is observability made simple. Thanks again to new relic for sponsoring today's episode of developer T. So, so there's a lot for you to be proud of in your work. Obviously people who are listening, they would like to probably emulate a lot of what you're doing. So if you're a developer, you're going to want to be proud of what you've done in your career. But I'm interested because everyone has areas where they don't feel confident. They don't feel comfortable. What is something that you are dealing with the uncomfortability of now? What are you least confident about in the work that you're doing on a day-to-day basis? Yeah, that's a good question. And actually it is related to something else I just realized I wanted to mention too about this. And that is, I'm going to try and teach something that you're not confident in or that you don't have some experience in. Like everything that I teach, I have really solid understanding and experience using these things. And I'm teaching you how I use them to great effect. And so I know that sometimes people will try to chase the money and they'll say, oh, well, you know, GraphQL is really hot right now. So I guess I'm going to go make a GraphQL course. I have not made a GraphQL course because I haven't actually, I haven't actually, really used it. And I'm not as cool as I think it is. I have so many other things that I'm excited about that it's low on the list. So I just teach the things that I'm excited about. And that ends up showing in the level of quality that I create. So the things that I'm uncomfortable with or that I'm not super great at are the sorts of things that I don't have courses or blog posts so far. So like, I'm not really super comfortable with CSS. I'm pretty bad at CSS. I can, you know, you give me a design, I can implement it, but it will take me a long time to make that and make it work well. Another example of something that I'm, I'm, I wouldn't say I'm ashamed, but like, I really want to be good at this, but I'm not, is animation. I think that would be really awesome to be good at that. But I just am so not. Another is I really want to be good at finite state machines. X, X state is a really awesome library that a bunch of smart people tell me is amazing. And I really want to spend time learning that but I haven't been able to find or put in the time to learn that stuff. So yeah, there's like a silly DevOps. I hate DevOps. I'm not at all. I barely get by making Docker containers and stuff and images and whatever. I, I'm not super into that either. Yeah, there, there's a lot of backend. I'm, I'm pretty passable at backend stuff, but I'm, I'm definitely focused on UI. And this is actually something that's played out really well for me, in general is just being really focused on on one area area. I know that a lot of people get a lot of value out of being polyglots. But if you want to be a really great teacher, you'll have a lot easier time doing that. If you are an expert, like the person everyone thinks about when they think about a particular technology, and it's really difficult to do that. Yeah. If you're a polyglot. So I decided early on, I'm a JavaScript engineer, that's what I focus on. And things outside of, of that, I'm just going to say, I'm sure that's cool, but it's not a cool thing I'm going to do. Yeah, wow, that's, that is a huge lesson in and of itself, right? You have to choose what you're not going to do. Especially if you're going to, you know, cultivate a sense of focus. It's very easy. It's tempting. Because there's a lot of cool stuff. There's a lot of cool stuff out there. And it's stuff that you probably have full mental capacity to be able to pick up on, and go and become, you know, really quite good at. But the fact that, you know, you've chosen this focused path, intentionally, not just because you love JavaScript. You know, it's not like you're religiously dedicated to JavaScript. There's no reason to do that necessarily, other than, hey, it's an intentional decision to cut other things out. It's an opportunity cost. Right, exactly. That's, that's, I think that's a really important lesson. And even for beginners, right? One of the most important questions I've gotten from beginners, that is reasonably hard to answer is, you know, which, which language should I choose? Which one should I pick up and run with? And I've narrowed it down. And I've made the answer simple, even though it goes against every fiber in my being to make this simple, you know, because it's not, it's not simple. But I answer. Basically, I have JavaScript and Python are like, my two main answers for beginner developers. And, and it's not because there are other, there aren't other good options. But because the opportunity costs that you would spend trying to decide between the hundreds of languages out there, and the 20 that are even marketable, is is already too expensive. Yes. If you're, if you're going to go and do something in AI, machine learning, whatever, if that's interesting to you. Then pick up Python. If you want to do basically anything else, then pick up JavaScript, right? That makes it a very simple heuristic. And now it's you don't really have to think about much more. What do you think about that concept of opportunity cost trade off and trying to make those simple heuristics and decisions in your career? Yeah, I think that when you're especially when you're a beginner, but even as an experienced engineer, you've been doing this for a while. Yeah, I think that when you're especially when you're a beginner, but even as an experienced engineer, you've been doing this for a while. What do you think about that concept of opportunity cost trade off and trying to make those simple heuristics and decisions in your career? There, there are so many decisions that you have to make, regardless of what you end up doing. And the more time that you spend making those decisions, the less time you have to make mistakes, I guess. And by that, I mean, experience comes from having experiences. And if you spend all of your time just like trying to make decisions, you'll have very shallow experiences with many things. And so you, you won't be able to provide an like, a good experience. Yeah, I think that's a good point. Yeah, I think that's a good point. Yeah, I think that's a good point. Yeah. Yeah. Yeah. And I do think it's also kind of a bit of a fallacy to believe that if you choose the wrong thing that it's a you know you're going to do in your career it's an irreversible decision you can never, you know, jump tracks, and you're a perfect example is you worked with Angular before you worked with React and in fact you learn something from React that you brought into your Angular work. Yeah. So imagining that you know that these are, these are one way decisions that you can't come back from is certainly a fallacy. Yeah. scary. It can be scary as a beginner developer to say, oh, I've gone down this wrong road. But as an experienced developer, you and I both can tell engineers it's not that way. You can absolutely change in the future if you find that it's important or necessary or even just desirable. If you feel like you're tired of this language, you don't want to do it anymore. There's so many lessons you can learn in any language and carry them to the other ones. Yeah, I totally agree. And there's not really, unless you're going to pick something that's very edge, like bleeding edge. Esoteric. Yeah, yeah. You're not going to make a wrong choice. It's highly unlikely unless you will know that you're choosing the edge thing and that might be a wrong choice. There's not any certainty there, but just go with the established stuff. And maybe eventually when you get experienced enough, you can start doing the bleeding edge stuff. Maybe you'll build the bleeding edge thing. Right. If you're just getting started or if you're just tired of making choices, then just choose the most popular thing and focus on that. Yeah. And for what it's worth, I mean, it's kind of hard to choose bleeding edge thing as a beginner anyway, because there's such a lack of material out there to even frame it, right? You probably won't even get to the problem solving portion because you're not even able to install it on your machine or something. It's just not going to work. And those other, the other tooling that you'll find is much more mature as a far larger audience. There's a lot of reasons to go with this advice, but I certainly agree with what you're saying there, Ken. So Ken, I want to ask you about Epic React, which I purchased a couple of weeks ago myself and I'm excited to kind of go through, but I know it's not just the same thing as purchasing a course on Udemy. Certainly this discussion, should have hopefully convinced people that that's not the way that you would run a course like this. So I'm interested in what makes it different from a Udemy course or even from the other JavaScript courses that I might find in the internet by other people. Yeah. So I'm glad you asked. This is something that matters a great deal to me. And as I was mentioning earlier, one of the biggest mistakes people make is getting into tutorial purgatory. And you could, you could get into that with something like Epic React where it has like, or like a Udemy course where it has a tutorial and you follow along and whatever. You don't end up learning a whole lot with that sort of thing. Like you'll get exposed to ideas, but you don't actually do the learning until you apply those ideas yourself. And by that time you're kind of on your own. You don't have any reference. There's nobody to talk to. And that can make it pretty hard, right? Yeah, precisely. And this is a big challenge for anybody making video courses. Like how do I make sure that the people who are watching this and experiencing this, whatever, that they actually take this with them. And so this isn't just like reference material when they need it in the moment, but it actually sticks with them so they can apply it when the moment comes. And so I've done a lot of research and given a lot of workshops and developed what I think is the winning strategy for helping people nail stuff down. So the problem for my workshops has always been that it's like a five hour workshop with an hour's worth of breaks. And so there's not a ton of time in that to cover a significant amount of material while also making sure that that material is just sticking. I used to do these at eight hour workshops and those last three hours were never useful. Like people just, their brains are dead and they're ready to move on. And so I've just, been really interested in figuring out how do I make sure I optimize for stickiness of this information. And so there's a book called Make It Stick that really impacted the way that I teach. And I apply several of the concepts of that research into the workshops that I give and Epic React specifically. So it's just the Heath Brothers book, correct? I can't remember. I actually did have an email conversation with the authors to ask them, you know, some of their opinions and thoughts on how we could apply those concepts to a workshop, but I can't remember the author's names. Yeah. I believe it is the Heath Brothers because I read the same book and I was blown away by the things I had wrong about learning and it really helped me think more thoroughly about it. Yeah. It was definitely a foundational change in the way that I approach teaching. So a couple of the things that we do that make Epic React really unique is that I don't teach you, before I expect you to do exercises. So with every exercise, and there are exercises, you spend more time at the keyboard than you do just watching the screen, like a lot more time if you're doing it right. But I will introduce a problem to you and then I ask you to solve it. So this resembles like your regular day-to-day work a lot better than just watching somebody solve it and then following, you know, doing them. So like the more traditional approach to workshop giving is, I'll go up and I will teach you about an API and I'll maybe do a little mini exercise and you'll just watch me do this and I'll teach you everything that you need to know about this thing and then I'll give you an exercise so you can practice what I just taught you. This is the wrong way to go about it if you want things to stick. What you're doing is basically what we do with like cramming information before a college final or something where you just like throw a bunch of information in your brain and then you just regurgitate it on the final and then you forget about it. This happened to me a lot in college. So, I just flip it around and I say, here's the problem and then I stop and I say, you go solve it. But then I don't just like throw you into the ocean and like, you know, sail away. I do provide a wealth of documentation. So like the expectation when you're on the job is you face a problem, you go Google around and you just try and find something and you'll find different blog posts and you'll find a lot of different things. You'll find posts that contradict each other and documentation that's out of date or whatever. So what I provide for you is I say, here's the problem and here are the different pieces of reference material you need to solve this problem. And then also in the exercises, I give you very hand-holding comments to help you be successful at working through this problem. And the effect that has is it forces you to kind of generate in your mind like, OK, so based on the information that I've got, I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. I'm going to do this. consumed, I now expect that I should be able to do it this way and it will work. And often it doesn't work. And for some one reason or another, and then you start to dig. Now, that's not a thing that happens when I just teach you how to do it. And then you just basically regurgitate what I said and I did. And so that process of generation, this is one of the things that's talked about in that book. You're generating the answers for yourself. Um, that is, um, a really important process for this information sticking. If you get it wrong, you remember it better. If you get it right, you feel really good about yourself. You also remember it better. And then on top of that, as you're going through it, because I haven't shown you how to do it, you're going to experience problems that you would not have seen if you just watch me do it first. And so all of these questions start to crop up in your mind, um, about like, okay, so what about, what if I do this? What if I do? Or like, why do I have to do it this way? You're going to start coming up with these questions. If you just watched me do it, then you're just going to take all of the, like those questions just won't come up because, um, I will do things in a certain way and you will just not realize that they could possibly be done a different way or, um, you won't have tried it first. And so you won't know what questions to ask. This is brand new material for you. And so you're, you're working through it on your own. You come up with all these questions and then I come through. And I, I show you how I would have done it. Now you may have done it differently. It doesn't matter. Um, but now you have all of these questions that like, as I'm working through it, they're, they're answered just boom, boom, boom, boom. Oh, okay. Now I, I, that makes sense to me now. Um, and these questions are answered. And if there aren't any, like, if you have some questions that aren't answered, um, then in a workshop setting, you can ask me those questions. Um, in Epic React setting, we've got a couple other things that I'll talk about later to help you with those types of questions. And so then the next. Key thing that we do, um, after you've, you've worked through these problems on your own and you've really got an idea of what, um, what, how to solve these problems with these tools that I've given you. Um, then I ask you to write down the things that you learned. And this is, um, what's called elaboration in that make a stick book where you have to, um, elaborate in your own words, the things that you learned in this process. And this will force you to think introspectively. Um, it kind of is that. Teaching portion of this consume build teach. So, um, this is, this is the entire idea behind my workshops and Epic reactive is I, we do that consume step where you're reading the documentation that I've written for you and any blog posts and links to docs and whatever. So that's the consuming part. Then the build is the exercising you work through that exercise. You're building something. And then the teach is the elaboration part where you're basically writing a mini blog post, explaining what you learned. learned in your own words. And that is what makes Epic React different. I don't know of anything else in the world that teaches anything like this. And based on the people that I've taught in workshops, as well as the people who are taking Epic React, the reviews are great. People are actually learning this stuff and being able to apply it in their applications. And so I'm just really excited about the way that we approach this. I created Epic React because I have all these workshops and I host them as remote workshops. People join there. I keep it down to 40 people to make it so you can actually ask your own questions and things. And then we move on. But because it's taking five hours of my time to deliver this workshop material, it costs a lot. The tickets are $600 a piece. And so that makes it, you know, and I've got eight... Workshops on Epic React Dev. And actually one of those is four workshops. So it's 11 workshops that you'd have to take $600 a piece. That is super inaccessible for people. And so that's why I recorded all of this stuff is to scale myself so I don't have to charge so much. And people still get an enormous amount of value out of it. But then you lose the ability to just ask me questions after each exercise. And so what I've done is two things. We have the KCD Learning Clubs, which is basically... It's like an opportunity for you to... To join other people who are trying to go through the same curriculum you are. And you go through that curriculum together and you set up a schedule and you follow that schedule together and you have a much better learning experience. You can talk with each other, answer each other questions. And that's a really important part of the whole learning process is because as you're asking each other questions, you're doing this elaboration or this teaching aspect of all of this. And then I also have my office hours that I mentioned earlier, where twice a week I'll give an hour of my time to do this. And then I also have my office hours that I mentioned earlier, where twice a week I'll give an hour of my time to answer people's questions. And that's what I tell people to do is just write down the questions that weren't answered as you were going through this. And then you can come and ask me during office hours. And so basically Epic React is all of the good parts of a live workshop with all of the good parts of a self-paced course put into one. And I don't know of anything else in the world that's like this. And it makes me really excited about the positive impact that I'm making on people's ability to learn React and build really awesome applications. It's exciting. And it's interesting. You mentioned that the workshop would be $600. And Epic React is worth a lot of money. And by the way, just to be clear, Kent has not paid me at all for this episode. Epic React, let's just do some math for a second. Let's imagine that you're doing a workshop with a lot of people. And you're doing a workshop with a lot of people. You get 1% better, 1% faster, whatever that metric is. Your hours are 1% more effective. So if we're talking about 101% of your normal output as a result of this work, then let's imagine that you put in 40-hour weeks like most people in the United States do. And you work, what is it? Something like 40 weeks. 45 weeks a year, something like that. So that's 1,800 hours or so per year that you're working. And if you were to do the math on that, I'm doing it right now as I speak, just for fun here. Let's see. I think that's going to be 18 hours worth of improvement in a single year. Okay. So let's imagine that you're, like most contractors, you're something like $100 an hour. That's 1,800 bucks, just in the easiest scenario in the first year of value. And again, I'm doing the math because I think it's the easiest way to kind of wrap your head around how this plays out in real life in terms of value. If you're 1% better as a result of this, that's $1,800 worth of value just like immediately. Would you agree with that kind of rationale? Yeah. You could think about it that way. You could also think about it, in like 0% to 100% because it's, I mean, there are other ways to learn React. Yeah. That makes sense. But if you can't get a job, then you're like, it doesn't matter how many hours you spend, like you're not going to. So it really, I think the best way to think about Epic React is a lot of people try to compare it to a Udemy course. And that's when they say, oh, like I can get a Udemy course for $400 on sale for $10 perpetually, because that's how you, you can get a Udemy course for $400 on sale for $10 perpetually. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Because that's how Udemy. That's how they work. It's so shady. I hate it. I don't want to get into it, but Udemy is a shady company. But anyway, and that's not the only reason. But like you compare, if you're comparing it to a Udemy course and you're like, well, what the heck? Like this doesn't make any sense. And if that's what I was comparing it to, then yeah, I would agree with you, but it's not, it is nothing like a Udemy course. It's actually much better compared to a coding school or a semester class. at a university where it's going to say like an actual, you know, hours based class at a university. Yes, exactly. It's like a three credit class at a university. You're saying where like the, the recommended schedule for going through Epic react is actually around 14 weeks. Uh, so there's, we, I just launched this, uh, a month ago today. Um, and, uh, nobody has finished it. Uh, and I, I, anybody who says that they finished it didn't do it right. Um, because it takes too long. There's too much material. There's like 350 videos or something. Um, but then you're spending more time, um, working on your keyboard than you are watching the video. So like, I even have people who've been using react longer than I have who aren't finished yet and working through it at a quick pace just because it is, it is so much stuff. So it's nothing like a Udemy course. Um, just not just in the amount of content, but also in the way the content is delivered and how memorable this will, and impact. This will be to your, uh, ability to be, uh, effective with react. So, um, yeah, the, like the, the amount of value is unquestionable. Um, it will definitely pay back the price for it. And, and the fact is like people were buying it at $600 a ticket per workshop. And that's what we're charging for all of the workshops. Uh, so like I said, it's, it's the best parts of live workshops without any of the worst parts, best parts of self-paced stuff, uh, like, courses without any of the worst parts. Um, so it is a killer value for sure. Yeah. I mean, break even on that is like, not, it's basically half a day of work, you know, like it's, it's just not, it doesn't make any sense to, and especially if you're working, if you're working for a company where react is like, uh, in the main line of your technology and that kind of thing, uh, it's, it's kind of this, this kind of resource. And it's certainly to this level of quality. I mean, it's, it's just, uh, like you said, there's not anything like it, uh, available. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Like think of it as a promotion. Um, or, uh, if, if you don't have a job, think of it as a job, like this is how you can get your, uh, your react chops up to snuff so that when you're in the interview, you're walking circles around the interviewer or, um, you know, if you have a job, think of this as your, your way to break out of junior and into senior level that that's what this people. Yeah, absolutely. Yeah. Uh, so we'll have to do an entire, entirely other episode, uh, about how you remain so prolific in your content creation, uh, because it's just an amazing amount of content that you've been able to put together 350 videos and a podcast, and you're continuing to write on your blog and you're doing an interview with me. How are you? How in the world do you have the time to do this? I post about that too. Again, thank you so much again, um, for, for spending the time with me, uh, here on developer T. I do have one last question for you, uh, if you'll allow it. Yeah. If you had 30 seconds of advice to provide to developers of all backgrounds, uh, all experience levels, what would you tell them? I think that there are a couple of things. It doesn't matter how good of a developer you are. If nobody knows that you're that good, um, you won't get the job, the opportunities that you want. You won't get the jobs you want. You won't get the tasks that you want. So you need to learn to communicate your abilities. You have to be able to do that. Um, also, it doesn't matter how much people know that you're a good developer. If you're not a nice person, people won't want to work with you. Uh, you'll, you'll get fired, whatever you need to be a nice person. And you want people to be on your side, in your corner, supporting you in whatever you're doing. And so you support them. They support you. You're a nice person. You're happier. And people know that you're a really good developer. So communicate and be nice. That seems so simple. It seems like probably good advice, for just about anybody. So that's, that fits well. Uh, Kent, thank you again, uh, for being on the show. Where, where should I send people if they want to learn more about your work and about Epic, Epic React? Go to kentcdodds.com and that will have links to everything. I've got my courses linked there. And, um, my newsletter is at the bottom. You can sign up and get an email from me every week, um, about one of the blog posts to level up yourself in whatever I wrote about that week. So that's, uh, I'm on Twitter and, and I have a discord actually, that's really awesome. Um, and all of that can be found on my website. I'm actually in that discord. So if you, uh, if, if you're listening to this right now and you join it, you send me a message as well. Thanks. Thank you again, Kent, for, for your time. Thank you. I appreciate your time too. Thank you again to today's wonderful guest, Kent C. Dodds for joining me on this episode. And the last episode of Developer Tea was a great interview. Kent is so gracious and giving with his, and giving with his time and a lot of energy. He really does want to teach, uh, and, and to make that a lifelong pursuit. And so hopefully you can become a student of his, go and check out his incredible project, epicreact.dev. This is, it goes beyond, uh, the, the normal, uh, kind of online course that you might be used to. Once again, Kent didn't pay us for any of this. Um, and certainly he is not, uh, sponsored us in the past either. So once again, just a huge thank you to Kent for spending time with me on, uh, these episodes of Developer Tea. Thank you to today's sponsor, New Relic. New Relic is observability made simple. Go and check it out. Head over to newrelic.com and you'll get a hundred gigabytes a month. Uh, you, it's all free, right? New Relic is all free. There's no host-based pricing, no constant upsell, a hundred gigabytes a month to one full access user. Go and check it out. Newrelic.com. Thank you so much for listening to this episode of Developer Tea. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. I hope you enjoyed it. See you soon. Thank you.