Learn By Consuming, Building, And Teaching
Kent talks about his three-phase process of learning something new.
Kent consumes as much information as he can about the thing that he's interested in, then he builds stuff with the things that he's consumed. The consumption process involves glancing over any related content or diving deep into a tutorial.
But then you actually have to build something, and not just follow a tutorial, but actually build a thing that you made up in your mind. Don't follow a tutorial. Then, go off and teach the things that you learned through blogging, meetups, podcasts, conference talks, etc.
Transcript
Michael Chan:
Hey Kent!
Kent C. Dodds:
Hey Michael!
Michael Chan:
So this is the end of our little podcast conversation talking about how to do all the cool things like a real pro, and we thought that it would be fun to finish off with just how to continue learning, how to take the stuff that you're learning in Epic React, take the things that you're learning from this podcast, take the things that you're learning from out about in the world, and what do you do with them? How do you keep learning? How do you stay on top of things?
Michael Chan:
So that's our starting point today. If you had to boil it down to one thing, one thing that has been key to your learning success, what is it?
Kent C. Dodds:
Consume, build, teach. That's kind of three things, but it's a process, right?
Michael Chan:
Yeah.
Kent C. Dodds:
I consume as much information I can about the thing that I'm interested in, or just things in general, to be able to have some sort of idea of what I might be interested in, then I build stuff with the things that I've consumed, like with some information. And that consumption process involves just glancing over podcasts, or any content, or diving deep into a tutorial or something.
Kent C. Dodds:
But then you actually have to build something, and not just follow a tutorial, but actually build a thing that you made up in your mind, or even I don't care if you're cloning another app, it doesn't matter. You just build something yourself. Just don't follow a tutorial. Then, go off and teach the things that you learned, and that is my learning philosophy.
Michael Chan:
I love it. Concise. Episode over, done.
Kent C. Dodds:
Yeah, that one was easy!
Michael Chan:
The build phase is really fascinating to me, because I think a lot of magic happens in there that we don't always... it's like x-factor, right? We can't really account for, and so I want to tackle that a little bit more, because like you mentioned, it's not just I read something or consume something type of thing, and then automatically teach it. You don't necessarily have a context for it at that point to teach it in any other way than the way that you just learned it. And so you are just kind of copy-pasting educational content, and that's not great. I mean, I guess it's fine. People do it.
Kent C. Dodds:
Yeah, they do. You can always tell because they can't answer the hard questions.
Michael Chan:
Yeah, yeah. So tell me a little bit about that building phase, what you would take on as a project? So you learn this thing and you're like, okay, I feel like I know it. How do you adapt it? So you read the React Todo app, right, and you're like, cool, I know React now. How would you go about actually building something new with the concepts you've learned?
Kent C. Dodds:
Yeah, I think that a lot of people get really ambitious when they see this cool new thing, whatever it is, Kubernetes or Docker or whatever cool thing, and they're like, I'm just going to build my own Facebook, or something, which is actually something I did try to do years ago when I was in school. But yeah, you just get these really huge projects in mind for this thing, and as exciting as that is and as much as you'll learn doing that, I think that you're better served trying to do something as small as possible for your first go at it. So, even if it is, like just your own version of a to-do app, or a mini-blog content management thing, or whatever it is for you. Like one thing that I built for my kids for Christmas one year is a typing app, because they were very small. So just seeing the letter on the screen and finding it on the keyboard, and pressing it and learning how to type that way. It was a single component, there was not much, but small things like that is what I'm talking about.
Kent C. Dodds:
Start with something really small. Don't be overly ambitious, because here's the secret: you can add stuff later. The difference between just starting huge and ambitious, and starting small and then adding stuff until it's this big thing, is that if you start huge and ambitious, then you'll try to push progress on all of these horses that are running, and none of them will finish; whereas, if you just focus on one horse that's running the race, then you can put that same amount of effort into that one horse and it will finish, and then you can kick off the next, and then kick off the next. And your abilities increase with every single one, so you'll be able to tackle more ambitious projects. The goal here should be, how do I get something done so that I can go from beginning to end in this whole building process?
Michael Chan:
Yeah. I think that something that has been valuable for me as I've learned is, as someone who's working in a code base that I don't own, a community code base, is really taking that opportunity to invest in principles. Do my to-do list app course, I learn a couple things, and I'm like, okay, what are the principles from that? And then applying that to your code and trying to transform stuff that has felt bad, into stuff that feels good and is easier to change, as we've mentioned in previous episodes. And embodies, I guess, the principles of the things that I've learned.
Kent C. Dodds:
I think that you can take notes as you're consuming on what those principles are, and I'm not much of a note taker. Of course, I'm not much of a consumer of other people's content. I learn through kind of different means, typically. Sometimes I will, but most of the time it's just lots of experimenting at source code and docs and stuff. I've taught a lot of people, and I've found that the people who are most successful are the ones who are really engaged in the consumption of my material. And really engaged in that learning process, that consuming, where they're taking notes, and in the process of taking notes, actually, that is really valuable because often you'll watch something, and if something doesn't quite click, then you'll just kind of gloss over it and you'll, oh, I'll pick it up later.
Kent C. Dodds:
But if you're taking notes, you've got to write something. And so if you don't quite get it, then what you write is a question. And then you can go take that to your Discord Cohort or to me later, office hours or whatever. And then you can ask that question. And so whatever it is, you want to be really engaged in that learning process. You have this wealth of notes of like, here are the concepts. Now let's take those concepts and apply it, just like you were saying.
Michael Chan:
Yeah. Now, something that I think a lot of people in the developer community don't necessarily talk about a lot, but it's really popular in sports and crafts, is this idea of repeated processes. Like just going out and like hitting 100 golf balls every day or going and shooting 100 free throws. I'm curious, how important do you think that is in coding type jobs? To just go out and spend 30 minutes writing a new thing using useEffect, or some hook that you don't feel like you have total mastery over yet?
Kent C. Dodds:
Dude, I love that. I think that's great. So that makes me think of this book, I can't remember, I think, yeah, it was Make It Stick, which I was planning on bringing up at some point during our conversation. It is so good. It's Make It Stick, The Science of Successful Learning. It was transformative for me in the way that I teach. And it very much informs just even the the way that I lay out the whole process of our workshops. And the one thing in that book that they talk about is, how they did this study where these kids just, I think they were throwing beanbags into a hole or something like that. And they had kids stand at five feet and just throw hundreds of beanbags into this hole. And then they had other kids who are going like, they'd do it at two feet, and then go to six feet and then three feet and then seven feet or whatever, like they just alternate. They would never throw it the same amount.
Kent C. Dodds:
And then they did this test where they're like, okay, five feet for both of you, see who can make it. And the kids who've alternated did way better. And so the idea that I was taught when I was little, it's just like, repetition, do it over and over and over again. That's how we practice sports. That's how we did spelling, all of this stuff, we just do it over and over. But what this research discovered is that it's not actually doing the same thing over and over, it's doing similar things just repetitively. And there's a lot more to it in the book, I strongly recommend people look at it. But so to apply that to this situation, I don't think that anybody listening would think that it would help them learn useState better just by typing useState over and over again. That would be useless.
Kent C. Dodds:
But what would be really useful is exactly what you said, just thinking of an idea for a custom hook or some sort of UI that you want to build, like go to one of the various design sites like Dribble or something like that, where they put up this thing. And build that user experience, build the part of the user experience that you want to improve on. So if you want to improve on implementing designs, then yeah, sure, go ahead and implement the design. If you just want to build that user experience, just with the JavaScript part, that's what you're trying to learn, then go through that. But the regular practice on using these different techniques and things that you've learned, is really critical. And then just doing it all over and over 100 times in one day, but doing it a bunch of times today, and then doing it a bunch of times in three days, and then a week from now. Spaced repetition is really what we're going for there. And that will make it stick a lot better than really anything else. You just really have to apply this stuff.
Michael Chan:
Yeah, I think it's fun. We used to do coding challenges for our kind of front end designer type of roles. And I always made it a point to do the challenge when trying to evaluate how much time it should take. And I was always amazed at the difference between kind of starting a project, and this happens every time I pick up a card for a feature or whatever. What you think it's going to be, like, I got this, I've done this so many times, I know exactly how this is going to look. You start and an hour in, you're like, that is not going to look. It's going to be completely different than I thought.
Kent C. Dodds:
Yes, yes.
Michael Chan:
It's like every problem has so much nuance in it. And I love this idea of, you don't want to just go and type useEffect, useState over time, like the computer can do that part for you.
Kent C. Dodds:
Yeah, yeah, you could write a software that does that, and you'd learn a lot doing that.
Michael Chan:
Yes, exactly. But that taking something that you want to know better, like useState and just hammering it with a bunch of different problems. Throwing every possible problem that you can think of at it, and seeing where it breaks down, where it excels, where you had to kind of do some weird thing, but actually it turned out all right, and well, that's your next library.
Kent C. Dodds:
Yeah, yeah.
Michael Chan:
All that kind of stuff.
Kent C. Dodds:
Yeah, absolutely. And very different problems too, right? Because it'll expose you to different parts of the API. Maybe making a counter component that's going to teach you the basic API, but then, if you want to put that counter value in local storage, well, now you have to start thinking about, what about the lazy initialization API part of it. And then, well okay, now we're doing something asynchronous and I've got stale closures, and so now I have to think about different things. So yeah, attacking it with lots of different problems is a really effective way to make sure that you have an understanding of the scope of the problem and the solution.
Michael Chan:
Yeah. Now imagine in Epic React, you actually go through a lot of these, you'd mentioned Dribble as a way of doing it for UI, but do you have any other recommendations for kind of problem spaces that are kind of small, unknown quantity and will give you that expertise? I don't know, like games or something like that.
Kent C. Dodds:
Yeah, yeah. So you can think of any Atari game and try to build something like that. I can't say that I've done that, I've done Tic-Tac-Toe, I've never done Snake or anything like that. But those types of games would be really interesting and fun. And you can share them with your friends and they'll play and they can appreciate it. And there's something to be said for being able to share what you've built with other people and having them use it and experience it and appreciate it. Or Build 2048 or just any of those type of games are a really great way. Because you can think about how to make those things work. Often that'll lead you into a graphics direction. And so if that's where you want to go, then that's a great place to go.
Kent C. Dodds:
If graphics isn't really your thing, then building little productivity tools that you could probably do in Excel anyway. But just build it just for the experience of building it. I have lots of little projects that are working. Well, one thing where I get lots of the inspiration for the software I build is, in my open source work. I don't have as many problems as I used to, because I eventually just built a tool that puts all of these things together. And now I just use that tool. And I don't really edit that anymore. But especially early on, having to write little scripts and different things like that to automate different processes was a really great place for me to be inspired. I wanted to write my own ESLint plug-ins or my own ESLint config or my own Babel plugins. All of it just kind of built on itself. Like, oh, I found this problem, this one open source library, so I made another one to solve that problem. But then there was a problem in this one, so I built another. And that's where most of my open source come from. Just like solving these problems I'd have in other open source situations.
Michael Chan:
I love that. Now, I want to incorporate this idea of learning through teaching. So you'd kind of mentioned your three-step process is to consume, build and teach. And we talked in the last episode about kind of strategies for teaching, building an audience, creating content, et cetera. And I kind of want to bring it home for people who are going through the Epic React content, you mentioned, note taking, what is a good way for people who are going through this course and haven't really stepped into content creation or that education teaching phase, what are some ways that they could share what they're learning as they're learning as they go through Epic React?
Kent C. Dodds:
Oh, man, that's a great question. There're so many ways. So you could do content creation of some form, like a talk or whatever. But I also am really excited about the Discord aspect of this, where you can share what you're learning with the group. So get together with a group, a cohort, schedule a regular time to meet with them and talk about the things that you're learning. Like you each spend a little bit of time. Or maybe even better, have one person assigned for each one, prepare something. Having a requirement to go prepare something is like, or a commitment that other people are expecting you to do something, is a really great motivator to actually get something done. So teach what you're learning to your coworkers. I actually get emails from people a lot when they read my blog, or on testing JavaScript.com, people will say, "Hey, are you okay if I teach what I've learned to my coworkers?" And I say, "As long as..." So here's my policy on that, if you're interested in doing this.
Kent C. Dodds:
If you're using my content, then you want to make sure that everybody knows where this content came from. Don't give them the impression that you made this. If you're not, you're welcome to take what you learn to make your own content and share that, you don't have to credit me at all, that's fine. But if you're using my stuff, you've got to credit me. If you're using my stuff, you can't get paid to do it. And if you want to get paid to do it, then come talk to me. I'll probably just say no, make your own stuff if you want to get paid. But yeah, that's basically my policy. Either create your own stuff or make sure that I'm credited for it. But that is totally cool. And I strongly advise that people do that. So yeah, share it with your co-workers, with your friends with your cohort, whatever, because that's just like a really great avenue for teaching this stuff.
Kent C. Dodds:
And in any form that you want, like a blog post, or I've seen a lot of people make a GitHub repo that has all of their notes and people contribute to it, that's actually really successful. Sometimes people will make a Google doc and everybody will collaborate on notes. Yeah, lots of different ways to share what you're learning.
Michael Chan:
Yeah, I find that illustrated stuff seems to be really popular in the dev community. So if you have like that skill set, that was actually kind of how I got my start. I was just doing sketch notes at conferences that I would go to-
Kent C. Dodds:
Really? Nice!
Michael Chan:
Yeah, it's super fun. And I feel like, if you are so inclined or gifted in that way, I'm sure that your Discord Cohort-
Kent C. Dodds:
Just everybody, yeah-
Michael Chan:
... You would appreciate that kind of stuff, yeah.
Kent C. Dodds:
I didn't think about that because I am so not that good at that. I am no artist whatsoever. But I absolutely, really appreciate when people make stuff. Not just in my content, but of anything, because it's a really great learning avenue or mechanism, or a good way to communicate. So yeah, love that.
Michael Chan:
Yeah. Yeah, yeah, it's fun. And I think that this really illustrates a point that we talked about in the last episode about content creation is that, there's so much that you can bring to... Like content that exists and interpret it and digest it and share it again in such a way that it feels like you, and that you're contributing to that work. And that's just fun. And I'm sure that you'd love to see people kind of dive into that as well.
Kent C. Dodds:
Totally.
Michael Chan:
Now, I know that speaking is a really big way for people to share what they're learning. And I know for me it has been kind of the final step in the learning process, for a lot of things that I've learned. That teaching phase as you mentioned. And I'd be remiss to not talk about it at all. So I'm curious, how did you get started in speaking? How do you think about speaking as part of this learning cycle?
Kent C. Dodds:
Yeah, yeah, this is great. So I'll just tell my first speaking story, because it's kind of a fun one. I've been speaking for a long time, just about anything in general. My first talk that I ever gave was probably in church. So even when I was a little kid, like four years old, I've been speaking. But speaking technically, the first time I ever spoke was at the first meetup I ever went to. Yeah. I was listening to a podcast and one of the hosts was Jamison Dance, and he was the organizer of a local JavaScript meetup here in Utah. And so he just mentioned it on the podcast. I was like, what the heck is a meetup? So I go to meetup.com, I'm like, oh, this looks interesting. And on it, it mentioned that they still needed a speaker. And I was like, I guess I can do that. I had no idea-
Michael Chan:
That's me.
Kent C. Dodds:
Yeah, that's me. I had no idea that like, they always need speakers at these things. So I was like, yeah, sure, I'd be willing to speak about something. And I had been building this open source project called GenieJS on the side, which is actually part of how I got my first job, which is another fun story. But I built this thing and I was like, I could teach people how to use this thing, I guess. Is that a thing that meetups speakers do? And so I gave that as a suggestion, I said, "I could present about my library." And he was like, "Yeah, okay, how long do you want to talk?" And we got it all scheduled out. And here's the fun thing that happened, as a part of that is, as the day drew closer, I was like, how am I going to do this? I've never spoken before. I've never talked about this kind of thing before. I've never seen a talk like this before. So I decided to make a workshop web app for this library. And that still is a thing. You can go through this workshop, it's this AngularJS thing.
Kent C. Dodds:
And it's actually an awesome way to learn how to use this library. So I probably should do things like this for my other libraries. But yeah, it motivated me to build this thing. And I was the creator of GenieJS, and I learned a lot of stuff about Genie in the process of doing this. Imagine if I were going to speak about some API that I just barely learned about, that process of preparing that material just really forces you to dive deep into this stuff. And actually, as the author of the library, I made changes to the API, to make it easier to teach. I do this all the time, so much of my open source stuff that I've ever taught anything about is changed in various ways, as a result of my process of creating this talk or any content of any kind.
Kent C. Dodds:
So anyway, I presented it and that ended up being my first ever conference talk as well. I adapted it, submitted it to a conference, and that was my first out-of-state conference talk. And yeah, there're so many things that happen in the process of preparing a talk that will solidify in your mind the concepts that you are trying to learn. Skipping that step of teaching is just doing yourself an enormous disservice.
Michael Chan:
Yeah, there's something about the pressure of having an audience, that really makes you feel like you need to know that thing, inside and out. And I've always loved that as a mechanism for really bulletproofing your understanding of a thing. Because, you'll learn so much having to build it. But you might not come into all of the edge cases. And like you said, as soon as you have to talk about something from the outside, this happens with documentation writing as well. When you start trying to explain it to somebody, you're like, that's not very good. It's just not good-
Kent C. Dodds:
I'm going to start that over. Or like, you get to that point, and you realize that it's just so hard to explain this, or they have to do so much work to just get to this point of understanding that you're like, maybe if I rework the API, I can make it so they don't even have to understand that. So it all feeds into itself.
Michael Chan:
Yeah, yeah.
Kent C. Dodds:
I like what you said, because it reminds me of a quote from Ashley Williams in one of the first episodes of JavaScript Air years ago, it was, teaching is nature's way of letting you know how sloppy your understanding is. And it's absolutely true. And hopefully you figured out how sloppy your understanding is before you're standing in front of people teaching. But sometimes it takes getting in front of people before you realize that. And I think there are plenty of times early on when I would go to teach people about things, and they would ask harder questions than I was prepared for. And that experience is a little bit embarrassing, but you learn to just say, I don't know, let's talk about that later, or whatever. But it really forces you to dive deep to make sure that you are ready for those harder questions. And I also want to caution people, don't freak out about this. It is scary, yeah, sure. I'm not going to say it's not a scary proposition to stand in front of people and talk.
Kent C. Dodds:
But most of the time, the people in the audience are not rooting for you to waste their time. They're actually rooting for you to be successful. And anybody who is rooting for you to fail are total jerks, and who cares about them anyway?
Michael Chan:
Man, I organized a meetup for several years. And it's so funny to kind of hear you talk about all these things. Like always having to hunt people down to speak, it's always hard to find someone to speak. And then yeah, the people in the audience, they want you to succeed. They wouldn't be sitting there if they wanted to watch you fail. And then, you have you have people who just want to kind of get in there and basically talk about how smart they are, with a question mark at the end of it, and that's not fun. But yeah, I think that, I guess in a very practical way, if you want to get into this, there's definitely an opening there. And you can always tell the organizer like, "Hey, I'm unwilling to take questions from the stage. Happy to do it one-on-one, but I'm not going to do it from the stage because I'm just not ready for that type of suspense and stress."
Kent C. Dodds:
Right. And most of the meetups I've been to were not so formal, where the organizer was the one who came and said, "Does anybody have questions?" So it's normally just like, you're the speaker, and you can choose whether to ask for questions or not. And you just say, "Thanks everybody." And you just walk away and that's fine.
Michael Chan:
Yeah, you can even do that after someone's asked a question and you don't know the answer.
Kent C. Dodds:
Yeah, like thanks everyone. I'm not going to answer that.
Michael Chan:
So do you have any other strategies, I think, in this speaking regard for people who want to get involved, but are still kind of on the fence about it?
Kent C. Dodds:
Here's kind of the way to trick yourself into speaking, you apply for conferences.
Michael Chan:
True.
Kent C. Dodds:
And you have to create your call or your submission or whatever, you get accepted and now you got to prepare the talk. You don't have to have the talk prepared before you propose. That would be ridiculous for a conference organizer to expect that. And so yeah, early on, I decided I like to be at conferences, I wanted to go. But I couldn't get my boss to send me to conferences all the time. But all of the companies I worked at were totally happy to let a conference pay for me to go. And they'd give me the time off to do that. And so, I just submitted to a ton of conferences. And I think I probably had like, a 95% rejection rate, only 5% of my talks were ever accepted. One year, I submitted so many proposals that I ended up speaking a lot that year, like 17 times or something.
Michael Chan:
Too many-
Kent C. Dodds:
That was way too many. I would not do that again. And that was a really hard year for a lot of reasons. But you just submit, and you can submit the same proposal to two conferences, just make sure it's relevant for those conferences. That portion of it is way easier than the portion of actually preparing and standing up and speaking in front of people. So that, I think is a good first step. And of course, speaking at a meetup is a lot easier, because normally you don't even have to make a proposal to speak at a meetup. You just say, "I'm willing to stand up in front of people for 20 minutes." Like, "Yes, thank you. I don't care what you're speaking on." You could speak on something totally unrelated, as long as it's not a bad thing, against our code of conduct.
Michael Chan:
Yeah, here's the code of conduct. You can talk about anything that's not on this list.
Kent C. Dodds:
Yeah, exactly. And they're totally happy to have you. So get yourself signed up. And if that's still too much for you, then I don't know any boss who's not super excited about knowledge sharing on a team. And so you just say, "Hey, team, I learned about this thing." And in that case, it can be a proprietary related to your specific application. And then you can you schedule a brown bag thing, everybody brings their lunch and you just talk during lunch. So lots of avenues to get yourself comfortable doing this. And from the perspective of somebody that, like we've both given lots of talks and I'm sure you can relate to this. The nerves never go away.
Michael Chan:
No.
Kent C. Dodds:
So don't feel like, oh, I'm such a inexperienced speaker because I'm so nervous, no. Everybody gets nervous before speaking.
Michael Chan:
So that's actually a really good tip. If you really want to humanize your heroes, speak at a conference that they're talking at, and sit in the green room with them, just stressing out, just sweating before they go on stage. It's like, oh, they're human too.
Kent C. Dodds:
For real, for real. There have been some conferences where my heart just like wouldn't stop pounding. And I was just so nervous. So yeah, it's absolutely, it's cool, it's fine, we're all nervous and we want you to be successful. And to bring it all back to the learning and stuff, maybe speaking in front of people isn't the part that solidifies it for you. But preparing the content, that is the part that is really going to force this into your brain. You don't need to stand up in front of people and deliver your talk and have them attack your talk with questions. Most conferences actually don't have q&a. And I like that. I don't like q&a at the end of a talk. Maybe a meet up is fine with q&a, but generally conferences, I don't like that. The q&a is not where you're going to learn this stuff. It's in the preparation of the content. And so even if you just prepare the talk, and never end up actually giving it to any anybody more than your spouse or your stuffed animals, you're still going to learn a great deal in that process.
Michael Chan:
Yeah, yeah. Now, you'd mentioned something that I think is really important, which is the idea that you can do things in whatever environment you feel the most comfortable. So if you feel the most comfortable with your co-workers, you've gone through all the Epic React content, you're like, hey, I learned all this stuff. I'm super excited to share it. I think that it would be an amazing thing for our team. Organize a small group of you and three other people who are really excited about this thing. Share what you've learned, maybe get them licenses, go through the whole thing together. There're so many ways that you can solidify your learning through teaching that don't involve an audience. And are a little bit more like, just you and a couple friends kind of figuring it out together.
Kent C. Dodds:
Yeah, yeah, totally low key. Yeah, it's all about preparing yourself, because in the preparation, you have to dive deeper than even in the building. Because if you're building something, and you just happen to miss this part of the API or something, then you just missed it. But if you're teaching, then you're going to go look at the docs, you're going to look at the source code, you're going to dive in a little deeper, so that you can explain, oh, can I only pass a string to that, or are there other things? It just becomes a natural part of your investigative process. And it's not just speaking either, like you're blogging, you're making a video, whatever.
Michael Chan:
Yeah, I think inviting other people naturally puts you into a position where you're exposing your preconceptions. You can only think of whatever, maybe 10 ways to use useState or whatever, and now you're out. But you hook up with someone else who can only think of their five ways or whatever, and there's going to be some overlap there, where it's like, you didn't think about those things. And seeing other people's use cases, adopting those into your patterns and the things that you know, is just so great for sharing. And I think that you even mentioned this, one of your big concerns about going full time educator, was that you would run out of things. Because now you're not building software anymore. But instead, the more people that you've been introduced to, and the more problems that they've had, now you've had 1,000 times more problems than you could have ever imagined.
Kent C. Dodds:
Yep, absolutely. And this is why I think it's so important to expand the learning experience from you just in your closet with your phone in front of your face. Like I've set it all up, so you're at the keyboard and everything and that's really important. You should do those exercises. And then on top of that, you should also share this learning experience with other people. Because you're exactly right, it forces you to think about things in slightly different ways. And they can share things with you may not have considered. And it's all like, building a product is exactly the same way. You don't want just 100 Kents in this room building this product. I want to have people with varying backgrounds and experiences because they bring things to the product that I would miss, if I just built it all by myself.
Michael Chan:
Yeah.
Kent C. Dodds:
And so you don't want to learn that way either. You want to have people coming in so that you don't miss anything that they would notice.
Michael Chan:
This is fascinating. A friend of mine had... he went to a MBA course at UCLA. And I remember him telling me that the the best MBA courses don't take you right out of your undergraduate work, they expect you to spend an amount of time actually working in a field, in an industry. Because the value of an MBA course or MBA degree is that you get a wealth of experiences from people who worked in different industries, who think about problems differently. Someone who works in manufacturing is going to think about things differently than someone who works in software. And getting those additional contexts really makes you a more robust professional. You're solving this in a really interesting way, and I want to kind of close out our conversation in how people can get involved, specifically in your community with Epic React with like-minded people with different contexts. And I think your solution to this is in Discord with cohorts. So tell me a little bit about that, your vision for that?
Kent C. Dodds:
Cohorts, it's basically, when I observed how awesome it was to have the this masterclass. I'll go through things together. And I've done this kind of thing before, I've gone to companies and given multiple workshops. And every time that I've done this, where people attend more than one workshop together, I've noticed this interesting thing where they actually get to know each other. Especially if they're at the same company. But even if they're total strangers at the beginning, by the end, they know each other's names and they're talking and they're not afraid to ask questions. And that was always something that was difficult for me, especially in live workshops is, I would just struggle to get people engaged with each other. And I noticed when doing remote workshops, I would make little breakout rooms. And I noticed that the breakout rooms of three to five people, the ones where people are actually talking and maybe sharing their screen and experiencing that learning process together, they always end up leaving me the feedback that indicates that they learned a lot, and that they remembered a lot.
Kent C. Dodds:
Every one of my workshop exercises has elaboration and feedback, where they have to say what they learned. And the people who were in those groups, that were actively involved together, were always the ones who could actually lay out what they learned and talk about it in an effective way. And they also ended up leaving me more positive reviews. So I was happy about that. So I've just kind of come to this realization that I think is a natural, it just makes sense, that people who are learning together will learn better. And so the cohorts idea was like, okay, I mean, the cohorts that's a boot camp thing. They're all called cohorts. They all go through things together. But KCD Cohorts on Discord is basically my way of just helping enable people to come together, who want to learn the same thing. And so yeah, maybe today you want to learn testing and tomorrow you want to learn React and whatever.
Kent C. Dodds:
I just want to put you with a group of people who are all motivated to learn the same thing with the same content, like we have a schedule of things that we want to learn. And then we follow that schedule together and meet on a regular basis to discuss the things that we're learning. And then the hope out of that, based on research that I've read, and just my own personal anecdotal experience, is that you will learn it and remember it better. And then you will also be motivated. You'll get some of the side effects of that teaching aspect, because you're talking about it with each other. And then hopefully, you can take it beyond that and start teaching it to other people, but you'll at least have the experience of consuming the information, kind of talking about it with each other. Hopefully building something with it, so that all of that learning process is complete.
Michael Chan:
Awesome. Now, what about someone who goes through this course and wants to get their hands even more wet? Wants to get their hands dirty with actually teaching people and leading people. Not necessarily ready to go off and start the content creation thing or doing public speaking, is there a place for people to like help lead other people in this KCD Cohorts arrangement?
Kent C. Dodds:
Yeah, so I can't scale very well. I'm just a single person. And I've got lots of things that I'm doing. And actually, even if I could, I would still do things this way for this reason, exactly. So the Cohorts program thing has a cohort leader. And that's really important to have one person who's the main person who's leading everything through this cohort. Because it gives the responsibility to somebody. So people aren't just like, the ball falls on the ground, like, I thought you got it?
Michael Chan:
Someone needs to cover the awkward silences and-
Kent C. Dodds:
Yes, exactly-
Michael Chan:
... the order of things. Yeah.
Kent C. Dodds:
Yep, yep. And so, there is a cohort leader. The cohort leader is typically the person who makes the application to create a cohort, but they don't necessarily have to be. And they're typically also the person who creates the schedule. And then we get people to sign up. And then that cohort leader is the one who communicates with me and says, or I'm thinking about automating this because I expect that it's going to be very popular when Epic React is launched. But I don't scale very well. But we'll create a text channel and a voice channel or video chat channel for your cohort. So you'll have a special place to communicate with each other. And then the cohort leader's responsible for finding time each week or every day or however frequently you want to do it, for people to meet. And actually, when Epic React is launched, I kind of have this anticipation that people are going to just connect separately outside of the Discord, and say, "Hey, let's go in this together." And then I'll just provide that space for them.
Kent C. Dodds:
So they'll be on the same page with all of this. But yeah, so you'll schedule. And if I can make it, I'll come to your first meeting and make sure everybody's on the same page. And then you just start going on your meeting. So the leader actually doesn't do a whole lot other than make sure everybody's on the same page and create that schedule. And then make sure there's no awkward silence during the meetings. And then I'll be available during my office hours to answer any questions and people can come during those times to ask anything. So as the cohort leader, you don't have to be a subject expert, you just have to be kind of the organizer and facilitator of that meeting.
Michael Chan:
Awesome. Well Kent, we're kind of at the end of this whole podcast journey. And I'm really excited that people have made it this far, excited for people going through the course, kind of learning all of the things that they would need to lead people in these discussions, maybe even take it further and start creating content of their own, from the things that they've learned. And I just wanted to give you a chance to kind of say any final messaging to the people who are going through this course and listening to this podcast.
Kent C. Dodds:
Yeah, so I just want to reiterate that my entire goal for Kent C. Dodds Tech LLC, the whole reason that I work, or even before this, and after this if I get a job, my purpose is to make the world a better place with quality software. So the entire Epic React, the intent is to facilitate making the world a better place, by teaching people how to create quality software. So if I've been able to do that for you by helping you learn how to use React effectively and how to build your products in a way that's better, more scalable, more easily maintained, then that's goal accomplished for me. And my hope is that you can take the impact that I've had on your life, and spread that impact further, by creating those awesome pieces of software, creating this awesome content to spread your impact even further, whatever it is, so that we can together make this world better.
Kent C. Dodds:
Because it's too bad to make it any worse. So let's just make this place better, a happier place to be. Something that I'm excited for my kids to grow up in, until the robots are writing all of our software and none of this matters anyway, anymore. But at least until then, let's use this amazing tool called React to do some really awesome stuff. And I hope that I've been able to help you learn that effectively. That's what I want to say.
Michael Chan:
Awesome, I love it. Kent, this has been a really fun thing for me to be involved in, to get spend like nine whole hours just hanging out with you, talking about all this stuff that we love. And how people can take your vision and actually internalize that, to write better software, take it to the places that they work, take it to out into the world, kind of help extend that vision to the places and communities that they really care about. So I'm really excited for all of the people that are going to be taking epic react. And I just thank you so much for all the things that you shared.
Kent C. Dodds:
Thank you so much, Michael, I really appreciate having this time to chat with you. You're a good friend.
Michael Chan:
You too. Until next time.
Kent C. Dodds:
Okay, see ya.
Michael Chan:
See ya.