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. But Kent also shares a lot of his knowledge totally free. And he also is kind of a lifelong teacher. We're going to talk about kind of the roots of why Kent cares so much about teaching in today's episode. My name is Jonathan Cutrell. 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. Let's get straight into the first part of my interview with Kent C. Dots. Kent, welcome to 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 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 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 that it's validating to hear 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 Chan's 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, you know, in my mind, I'm thinking like you went on a retreat and tried to figure out like what do you want to do with your life. What do you, how did you arrive at this idea and to be clear, you know, you can use your own words 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. 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 testing JavaScript.com. That's a great way to test and show people how to test. And I made epic react.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 the typically the way that you share something is by teaching in some form. And so yeah, speaking in front of crowds has been something that I've done since I was like a kid at church. And 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 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 my time trying to teach the things that I was learning as I was building the products to my fellow co-workers. 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. And 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. I've gone through this for many years and at some point I kind of came to a crossroads where I was like, okay, this is something that's taking a good amount of my time. And it's worth it. But I want to make sure that it's 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 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 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 later in later stages as a more experienced engineer, for example. What are the differences there? And when do you feel, when did you feel qualified? That's a great, also a very insightful question. So, 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, like you can't, you don't really understand something until you've started teaching. And so the natural 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 when I, the metaphor that I normally use to talk about this is, like, 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 or 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? Like, 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, 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, you know, 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, you know, with, with brick and mortar stores, you, you put up a bunch of McDonald's because, you know, one's closer than the other, whatever. But, yeah, with the internet, I have access to all 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, a blog, but maybe you're doing YouTube videos or giving talks or whatever, you know, 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. You know, 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 what 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. So because of that pushback, 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 say, okay, I'm using this CSS and JS library. I'm using emotion. And I like it better than styled components or I like it better than using CSS monitors. So it's just regular CSS. And so like you've just developed this opinion naturally. But then somebody's going to come and ask you, like if you try to teach it, somebody's going to come and ask you, okay, so why? Why do you prefer it this way? And it triggers this response in yourself of introspection where you're thinking, you know what? I really need to come up with a reasonable argument for the way that I feel. And eventually you may end up changing your opinion or solidifying your opinion further. But it does cause you to dig into the implementation. Like you have some assumptions like, oh, well CSS and JS is faster 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. And if just spout out falsehoods or things you don't know, then like you probably know that you're doing that and you shouldn't. You shouldn't just spout out falsehoods. 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 makes teaching such a solidifier of knowledge? Yeah. Yeah. That last part is actually was was my theory of why it why it works so well is you kind of assume the role of the person who's trying to challenge what you know. So the questions of why it why is it that way? You know, you may not have asked that to begin with. 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 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 subjective feelings about the thing which are very possibly correct, but also possibly wrong. And you have to objectify them as much as you can. And back them up with with true evidence like another thing as I'm learning to teach react, I'm 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. And so, you know, reactant 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 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 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 support 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 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 the case may be. But as you're preparing that information that you're trying to share with other people, it 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 your 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 and accessible cloud computing solutions. You can get started on Linode today with $100 in free credit. $100 goes a long way on Linode, by the way. $100 in free credit for listeners of Developer Tea. You can find all the details at linode.com slash Developer Tea. 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, 7, 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, the biggest account that Linode has. There's no tears. There's no human support tiers. Everybody gets that high level support from Linode. No handoffs, regardless of your plan size. You can choose shared and dedicated computants as well as you can use your $100 in credit 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 Tea. You can click create free account. That's a button. Click the create free account button to get started and get that $100 of credit. Thanks again to Linode for sponsoring today's episode of Developer Tea. I think it's almost religiously accepted that problems are our best teachers as engineers. Often we do learn so much from the practical problems that we face. I think it was a, of course, it was a program essay on Lisp. He talked about why Lisp was a more powerful language. Of course, he's very opinionated because he used to. He says it in 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. 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 second hand or second nature rather. 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. It seems like there is some other approach. To go and just look at the tool set itself as 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 a React Summit and it's called Consume Build Teach and that is my process for learning anything. So you like the basic idea is you consume information so that you know it'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 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 solving the problem. And that's really the recipe for true learning. Yeah, it's interesting because there's this obviously there's this connected relationship between teaching and learning. And you certainly are, there 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, not learning anything specific, but the process of learning? Who? So I have a couple of thoughts about this, but they basically boil down to thinking that learning is a passive experience. I guess people who get stuck in the consumption side of the equation, they consume things, they never really build anything and if they do, they don't teach the things that they've learned. And so without all three 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. So I see this very often where people will sit back on their recliner, flip on the Chromecast and watch a four hour or maybe a 40 hour course on you to me or something. And by the end of it, they think that they've learned what they watch, but they really didn't. And you won't have that information at hand. Now there is benefit to doing this. 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 that. So then you can go reference it later. So like there's something happening there, but it's not learning. It's just cataloging of information. And our brains are pretty, they're pretty amazing, but they're also really great at garbage collection. And so if you don't try to reference that catalog item, then you're going to forget it in the future, not too distant future anyway. So it's not really true learning. And so yeah, just sitting back and passively watching material or whatever reading blog post, another thing that I see that's related to this is tutorial purgatory where you just you buy a course or you 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 will not learn stuff just rehashing what other people are doing. And so and this is actually something that I specifically combat in epic react.dev where like most teaching material, actually I'll stop right there and I can talk about my strategy on epic react.dev, but I'll go ahead and stop because I can talk a lot. Well, I do want to get into it and perhaps this will actually open us up into that, but I want to ask you a question that I like to ask all my guests. What do you wish more people would ask you about? What is something you wish more people would ask you about? I don't know. I guess I get so many questions like a ridiculous amount of questions because I try to be really accessible to people. In fact, I've started doing office hours. So twice every week I'll give an hour of my time to just answer people's questions and that way I can kind of batch answer a bunch of things. So I get questions about a lot of stuff. Yeah, I don't know. I think see, like stuff that comes to mind is like, how can I help you with what you're doing? But I actually get that a lot and it's hard to accept or like I always accept people's help, but I'll just, this is a bit tangential, but I'll just mention it because I think there are some interesting takeaways. So when somebody comes to me and says, hey, I want to help you do something. I just want to help you with your open source or with your blog or something. And so I'll say, okay, well, here's a thing that I want done. I need 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 this. This does work out sometimes, but I need this pull request. I need this thing worked on or it doesn't end up playing out very well most of the time because it's not your own problem that you're solving. I realized that was not at all what you were asking about, but it's just something that came to mind. 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 just hold your breath a little bit longer and you'll find out that you do have a problem, right? Yeah. Yeah. You have problems. And just trying, 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 you're much more effective when you have, you have felt the pain that you're trying to solve. So anyway, that's not related. I'm not sure what questions I want people to ask me about. It's a hard one to answer, especially for someone like you who you probably are getting a lot of questions about things that you do like to talk about and perhaps questions that you've answered a hundred times. You've mentioned this before on React Podcast where you have kind of pre-formed answers in the form of a blog post for these extensive questions. But I guess the underlying concept there is, what is a topic that is really kind of, that you have a lot of energy to talk about whenever it comes up? That's really kind of the thrust of the question. Oh, yeah. I don't know why, but testing is always something that gets me excited. I can talk forever about testing. I honestly, like I said, I don't know why. It seems like such a dull topic, but I can talk about it forever. I'm also like anything that's on epicreact.dev, all of those workshops I could talk about those for a long time. So react to something that gets me really excited. Yeah, I don't know. I mean, there's non-tech things. I get really excited about the future of energy, you know, battery and stuff solar. I'm super bullish on autonomous vehicles. I have a Tesla. It's amazing. I could talk a little bit about artificial intelligence and its impact on software. I'm not super well versed in it, but it's a topic that gets me interested in kind of what our future looks like in the next 10 years or so. So yeah, those are a couple of things that I kind of enjoy talking about. Yeah, I think actually 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 we must have had some pretty similar experiences since then of the kind of the process of acclimating to that kind of autonomous vehicle. It is definitely an experience. Yeah, it changes you, man. Well, I do want to talk about testing, and I want to talk about it. Maybe we can actually frame it in the lens of something like looking at Tesla, right? Obviously, we're not talking about testing front-end components necessarily with Tesla, but we can think about the importance of a test in terms of its consequence. I certainly hope that we have a lot of tests that are backing our experience when we're turning on the navigation mode on our Tesla's, right? Because the consequences are huge there, but I'm curious about what you think about this. 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, they 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 dealing with trivial things, not so important, versus areas that are much more important, like payment pathways and that kind of thing? Yeah, so I have a blog post about pretty much any subject you could ask me about testing. I have a lot of, I've written about this a lot. I need to write a book, but my thoughts on testing coverage are, you framed it really well, like not every line of code matters as much as the next. So this line of code has something to do with the settings page for admins only. Okay, so maybe that's important that they can change their display name or something that we want them to be able to do that. But then this other line of code over here is what controls the car's ability to turn left. Or that's a pretty important line of code. The problem with code coverage is that that metric doesn't give you any insight into how important that code is at all. It's just a metric. So you can have 100% code coverage on that settings page and 0% code coverage on self-driving. And that's not a good thing. So I don't really, I don't take too much stock in the coverage report itself. Now, our tools do have the ability to say, okay, like this area of the code base needs to have this no percent of coverage and this area of the code base doesn't, we don't care as much. So I would recommend configuring things that way. But like the biggest challenge is you never really get a sense out of these automated tools. Like how confident you actually are that you can ship your software. Even if you were to have 100% code coverage, that's not going to tell you that you're confident in shipping your software either. And so what I typically try to think about when I'm testing a code base is how do I think about the use cases that I support and how much use case coverage do I have. And that's what 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 considering in my test yet. 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 impossible to really quantify. But that's what I think about when I'm testing. Yeah, it's tough because we don't have ways of, I'm sure there are ways of probably entire libraries to do this. But marking the severity level of a particular method. How do you know that that's a really important one? And that it should be covered twice, right? That's a difficult thing. And you kind of have to have experience with the code base in the average code base. Like I said, I do think they probably have some kind of like meta marker kind of decorators or something like that. To say, hey, this particular method, this one's really on the critical pathway. Don't mess with this unless you really know what you're doing or unless you are certainly covering it well with tests. So that's an interesting problem to solve. I'm interested to know also, if we're talking about testing and we're talking about kind of practical building of software, it's very, I would say it's kind of easy to come up with a project, right? Like you said, in tutorial, what did you call it? Tutorial purgatory. Yeah. It's easy to come up with a kind of a pet project to write for tutorial. And it's very clear what the test should be. You can see the use cases. It's all on a perfect spreadsheet. That's easy. But when it comes to practical problems, where there's crossover or there's dependencies outside of your project, or there's things that are outside of your control. Maybe there's some legacy code you're dealing with. How do you navigate those kinds of problems? So 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 tutorial purgatory is such a problem because you don't face unexpected problems often. Like you, you will sometimes, but everything's really well laid out for you and you typically don't have to make these kinds of decisions. 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. But I basically, 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 maybe it's an e-commerce site. I really want to make sure that checkout button works. Now you wouldn't be able to enter in your credit card and do the checkout, enter in your home address and everything. Do the checkout every single time you want to release. That could cost a lot if you're selling boats or something. So you will need to set up some tooling around that to make sure you're not actually making a purchase of a boat. And there are strategies that I can teach you on testinjobscrap.com and how to skip that portion. So you're not actually buying boats every time. But 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've already feel really confident with your automated test suite, you're covering those use cases, then you can move down to the next year. If this would be pretty inconvenience, 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. 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 your you prioritize things. I actually have a blog post about that too. So yeah. A huge thank you to Kent C Dodds for joining me on today's episode and the next episode of Developer Tea. 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 epicreacts.dev. Thank you to today's sponsor, Linode. Linode is going to give you $100 in credit as a listener of this show for creating a free account. Head over to Linode.com slash Developer Teato get started with that $100 in credit today. Thanks so much for listening to this episode of Developer Tea. This episode and every other episode of this show up to this point is available on spec.fm. Head over to spec.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 Tea. 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 Cutrell and until next time, enjoy your tea.