Vox

Leitura de 37 min

Teaching in Public w/ Kent C. Dodds (part 1)

Summary

In this episode, host Jonathan Cottrell interviews Kent C. Dodds, a renowned educator in the React and JavaScript testing communities. Kent explains how his natural enthusiasm for sharing knowledge evolved into a purposeful career dedicated to teaching developers. He discusses the roots of his teaching philosophy, tracing it back to his childhood experiences speaking in public and his realization that teaching others to write better software creates a larger positive impact than solely building software himself.

The conversation delves into the mechanics of how teaching solidifies learning. Kent argues that teaching forces introspection and deeper investigation into tools and concepts, often revealing use cases and details that practitioners might overlook. He addresses common beginner concerns about not being “qualified” to teach by comparing the landscape of educational content to having multiple coffee shops or burger joints—different perspectives and teaching styles cater to different learners, and the act of creating content itself is where the primary value lies for the teacher.

Kent introduces his “Consume, Build, Teach” framework as the recipe for true learning, critiquing passive consumption and “tutorial purgatory” as ineffective. The discussion then shifts to practical aspects of software testing, where Kent shares his thoughts on code coverage, prioritizing tests based on risk and consequence (like critical payment pathways vs. admin settings), and strategies for adding tests to legacy or complex codebases. He emphasizes thinking in terms of “use case coverage” rather than just line coverage.

Recommendations

Concepts

  • Consume, Build, Teach — Kent’s three-step framework for effective learning. First, consume information to see what’s possible. Second, build something to apply the tools. Third, teach the material to solidify understanding by diving deeper than practical use typically requires.
  • The Testing Trophy — Referenced by Jonathan as Kent’s model for thinking about testing. While not elaborated on in detail here, it’s presented as a well-known concept from Kent’s body of work on testing methodologies.

People

  • Paul Graham — Mentioned by Jonathan in the context of an essay on Lisp. Graham argued that Lisp empowers programmers in ways other languages don’t, introducing tools and concepts they wouldn’t even know were possible, highlighting how tool choice influences learning.

Websites

  • epicreact.dev — Kent’s comprehensive learning resource for React developers. Jonathan mentions it as some of the most important teaching material he’s used, and Kent discusses his specific strategies on the platform to combat tutorial purgatory.
  • testingjavascript.com — Kent’s course on JavaScript testing. Jonathan credits it with teaching him most of what he knows about testing, and Kent references it for strategies on testing complex scenarios like e-commerce checkouts without making real purchases.

Topic Timeline

  • 00:00:00 — Introduction to Kent C. Dodds and Teaching in Public — Host Jonathan Cottrell introduces the episode’s theme of learning and teaching in public. He welcomes guest Kent C. Dodds, highlighting Kent’s significant contributions to React and JavaScript testing education through resources like epicreact.dev and his free content. Jonathan sets the stage for a discussion on why Kent is so dedicated to teaching.
  • 00:01:54 — Kent’s Journey to Identifying Teaching as His Purpose — Jonathan asks Kent how he arrived at the conclusion that his best contribution to the world is to be a teacher. Kent describes it as a natural extension of his personality—he’s always been enthusiastic about sharing what excites him. He realized that while building software has impact, teaching others to build better software amplifies that impact by empowering them to improve their own corners of the world, which led him to go full-time as a teacher.
  • 00:07:08 — Teaching as a Beginner vs. Experienced Engineer — The discussion explores when someone feels qualified to teach. Kent addresses the common beginner concern that everything they know is already online. He uses the metaphor of multiple coffee shops or burger joints to explain that different teaching styles resonate with different people. More importantly, he stresses that the value of teaching comes from the production of content, which forces deeper understanding and solidifies knowledge, regardless of whether anyone consumes it.
  • 00:10:05 — Why Teaching Solidifies Knowledge — Playing the skeptic, Jonathan asks why teaching helps you learn if you already know something. Kent explains that teaching invites questions (real or anticipated) that challenge your assumptions. This forces you to introspect, research, and objectify your subjective feelings about a tool or concept. You often explore aspects of an API or tool you’ve never needed in practice, leading to a more comprehensive understanding.
  • 00:17:54 — The Consume, Build, Teach Learning Framework — Kent outlines his three-step framework for effective learning: Consume information to know what’s possible, Build something to apply tools and face problems, and Teach what you’ve learned to dive deeper and solidify understanding. He contrasts this with ineffective learning patterns like passive video consumption or “tutorial purgatory,” where people only rehash tutorials without building their own projects or teaching the material.
  • 00:26:59 — Philosophy on Testing and Code Coverage — The conversation turns to software testing. Kent discusses how to think about test coverage, emphasizing that not all code is equally important. He argues that line coverage metrics are flawed because they don’t indicate the importance of the code. Instead, he focuses on “use case coverage,” prioritizing tests for critical pathways (like payment processing or, in a Tesla, the self-driving code) over less critical areas. The coverage report is only useful for identifying untested use cases.
  • 00:30:59 — Adding Tests to Complex and Legacy Codebases — Jonathan asks how to approach testing in messy, real-world scenarios with dependencies and legacy code, beyond simple tutorial projects. Kent advises starting with a risk analysis: identify the parts of the application that would be “really, really bad” if they broke (e.g., checkout functionality). Test those critical use cases first, then move down to lower-priority areas. He frames test writing as a prioritization exercise, just like feature development, balancing new features against the need for stability.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-11-30T10:00:00Z
  • Duration: 00:35:02

References

Podcast Info

Transcript

[00:00:00] Over the next couple of episodes of this show, we’re going to be talking to two guests.

[00:00:08] Both are totally dedicated to learning and teaching in public about code.

[00:00:15] Today’s guest is Kent C. Dodds.

[00:00:17] Kent has created some of the most important teaching material that I’ve used for React

[00:00:24] developers.

[00:00:26] You can find that at epicreact.dev, but Kent also shares a lot of his knowledge totally

[00:00:32] free, and he also is kind of a lifelong teacher.

[00:00:37] We’re going to talk about kind of the roots of why Kent cares so much about teaching in

[00:00:42] today’s episode.

[00:00:43] My name is Jonathan Cottrell.

[00:00:44] You’re listening to Developer Tea, and my goal on this show is to help driven developers

[00:00:48] like you find clarity, perspective, and purpose in their careers.

[00:00:53] Let’s get straight into the first part of my interview with Kent C. Dodds.

[00:00:57] Kent, welcome to Developer Tea.

[00:01:00] Thank you so much for coming on the show.

[00:01:02] Thank you.

[00:01:03] I’m just so pleased to be here.

[00:01:04] Well, I want to first start out with a huge thank you because the work that you’ve done

[00:01:10] has influenced my career heavily.

[00:01:14] JavaScript testing, for example, I’ve learned most of what I know about JavaScript testing

[00:01:19] Having come from kind of a Ruby on Rails background, when I was using just the jQuery and manipulating

[00:01:26] the DOM back in the day for fun, and then realizing, wait a second, we’ve got to build

[00:01:30] the entire application in the front end now, I wanted to bring testing, but I didn’t really

[00:01:34] understand it fully, and you helped me understand it, so thank you for that.

[00:01:39] I’m so glad.

[00:01:41] It’s validating to hear that the work that I’ve put in has helped somebody out, so that’s

[00:01:47] good.

[00:01:48] Well, I want to talk to you about that in today’s episode because I’ve heard you talk

[00:01:54] about this, for example, on React podcast, on Michael Jantz podcast, you talk about kind

[00:02:00] of what you believe your best offering is to the world to make it a better place, and

[00:02:06] the way that you talk about it, it made me think that you’ve really put some thought

[00:02:10] into this.

[00:02:11] This wasn’t accidental.

[00:02:13] It seems like you’ve, you know, in my mind, I’m thinking like you went on a retreat and

[00:02:17] tried to figure out like, what do you want to do with your life?

[00:02:22] How did you arrive at this idea, and to be clear, you know, you can use your own words

[00:02:28] to explain it, but from what I understand, you feel like your best contribution to the

[00:02:34] world is to be a teacher.

[00:02:37] I’m interested in how you arrived at that conclusion.

[00:02:40] Yeah, that’s a very thoughtful question.

[00:02:45] I’ve always been one to share what I know.

[00:02:49] I’m a very enthusiastic person, and when I’m excited about something, then I like to share

[00:02:53] that with other people and try to get other people as excited about it as I am.

[00:02:59] It’s kind of funny, I’m relentless in that, where regardless of whether they’re receptive

[00:03:07] to that, I just seem to not care, and I’ll just be excited about it.

[00:03:12] I like to share the things that I find interesting, and that typically naturally comes out of

[00:03:19] trying to explain something to somebody, and so I’m really excited about testing, and so

[00:03:24] I made testingjavascript.com as a great way to test and show people how to test, and I

[00:03:31] made epicreact.dev so that I could teach people how to, this thing that I’m really excited

[00:03:36] about, React, and how to use that effectively.

[00:03:40] It’s always really been part of my personality to share what I’m excited about, and typically

[00:03:46] the way that you share something is by teaching in some form.

[00:03:52] Speaking in front of crowds has been something that I’ve done since I was a kid at church,

[00:03:58] and when I started doing software, it was just a natural thing for me to start speaking

[00:04:06] at meetups and hosting workshops and things like that, and going to conferences to speak

[00:04:12] at conferences and things, and I think I realized after a while that I could build products

[00:04:19] and I could impact a lot of people and make a positive impact in the world, but I just

[00:04:25] naturally spent more of my time trying to teach the things that I was learning as I

[00:04:30] was building the products to my fellow coworkers, and I realized that if I can make a big impact

[00:04:35] by writing good software, I could make a better impact, or an even bigger impact, by teaching

[00:04:41] other people to write better software faster, because then they can take the things that

[00:04:46] I’ve taught them and go off and make their corner of the world a better place.

[00:04:51] That’s kind of where I’ve landed and why I’ve gone full-time as a teacher, because I’ve

[00:04:56] realized that I can make the best positive impact on the world by creating software,

[00:05:04] and I can do that best by actually teaching other people to create software better.

[00:05:09] It’s interesting, because it’s very similar to the reason why I decided to continue this

[00:05:14] podcast.

[00:05:15] I’ve gone through this for many years, and at some point I kind of came to a crossroads

[00:05:19] where I was like, okay, this is something that’s taking a good amount of my time, and

[00:05:25] it’s worth it, but I want to make sure that not only is it worth it from a financial standpoint,

[00:05:32] but also that it’s doing something that I care about doing in the world, kind of as

[00:05:37] my, whatever you want to call it, your legacy, your purpose, something that is deeper than

[00:05:43] just being successful by some external metric.

[00:05:47] There’s some internal satisfaction, and I arrived at something very similar to what

[00:05:52] you’re saying, that software is incredibly important.

[00:05:54] It’s shaping the world, perhaps more than any other type of artifact.

[00:06:01] It’s a very impactful thing, and it’s impactful both internally for software engineers, but

[00:06:07] also externally for the rest of the world, the people who are using the software and

[00:06:12] the gradient of people in between, the people who are kind of casual software engineers,

[00:06:16] if you’re sure that’s a thing, right?

[00:06:19] And so I came to the same conclusion that one of the most important things I can do

[00:06:23] is try to talk to those people, talk to the people who are interested in it, or even

[00:06:30] who are feeling like they might be interested in it.

[00:06:34] And that’s actually another piece of your story that I want to ask you about.

[00:06:39] You’re interested in teaching, but there has to be a gap at one point where you, it’s

[00:06:46] kind of this knowledge gap where you’re still learning yourself.

[00:06:50] And I’m curious about how you think about teaching as a beginner versus teaching in

[00:06:58] later stages as a more experienced engineer, for example, what are the differences there

[00:07:04] and when do you feel, when did you feel qualified?

[00:07:08] That’s a great, also a very insightful question.

[00:07:11] So and it’s a question that I get from beginners a lot because I’m always telling people that

[00:07:17] you need to teach to solidify the things that you’ve learned.

[00:07:20] Like you can’t, you don’t really understand something until you’ve started teaching.

[00:07:25] And so the natural question for beginners is to say, well, somebody already wrote a

[00:07:29] blog post about everything that I know.

[00:07:31] Like the content for everything that’s in my brain is already on the internet.

[00:07:36] So why would, how could I possibly contribute anything?

[00:07:39] And what I, the metaphor that I normally use to talk about this is like, have you ever

[00:07:47] seen a Burger King and a McDonald’s, you know, side by side on the road?

[00:07:54] Or there’s even like a place in Texas where they have a corner, four corners on the street.

[00:08:03] And three of those corners has a Starbucks.

[00:08:05] So there’s three Starbucks on the same corner in some place in Texas.

[00:08:09] So why do they do that?

[00:08:11] Like didn’t they already solve this problem?

[00:08:13] The problem of I need a coffee or the problem of I need a burger, they solved it already.

[00:08:18] So why would they do something like that?

[00:08:21] And the reason is because there’s enough of a market for the different things that these

[00:08:26] have to offer.

[00:08:27] I’m not so sure about the Starbucks thing.

[00:08:29] That seems a little gratuitous, but at least for, you know, for the different flavors of

[00:08:35] burger, it makes total sense.

[00:08:38] It’s a little bit different because we’ve got the internet.

[00:08:39] And so I don’t have to, you know, with, with brick and mortar stores, you put up a bunch

[00:08:45] of McDonald’s because, you know, one’s closer than the other, whatever.

[00:08:48] But with the internet, I have access to all, everything that’s public everywhere.

[00:08:55] But that’s not really what makes one person go from one to another.

[00:08:58] It’s not just the accessibility or relative accessibility of content.

[00:09:03] It is how accessible is that content to that individual?

[00:09:08] Everybody is going to teach this content in a different way.

[00:09:11] But then even more than that, even if nobody reads your content, you wrote the content

[00:09:18] and there’s a lot of value out of doing that.

[00:09:21] And maybe it’s not writing, maybe you’re doing a blog, but maybe you’re doing YouTube videos

[00:09:26] or giving talks or whatever, you know, making a workshop or something.

[00:09:32] But the idea is the process of that creation is how you’re going to solidify what you’re

[00:09:38] trying to learn.

[00:09:39] And so it really is irrelevant, you know, whether people consume your content.

[00:09:43] It’s the production is where the value comes in.

[00:09:46] Producing that content is where you’re going to get the value out of it.

[00:09:51] So whether you’re a beginner or super experienced, you need to produce the content to really

[00:09:57] solidify your understanding of it.

[00:10:00] I’m going to play the role of a skeptic and ask why?

[00:10:05] Why does this help for me to say, well, I know this already, I can show you, I know

[00:10:10] it, I’m using it in this project over here.

[00:10:13] Why does teaching it help me become any better, any more thorough of my knowledge here?

[00:10:18] And I have a theory as to why, but I’m going to keep my skeptic hat on and let you answer

[00:10:22] first.

[00:10:23] Yeah, yeah.

[00:10:24] The skeptic actually is proving my point.

[00:10:26] So because of that pushback, that question that you’re giving me, it’s causing me to

[00:10:31] be more introspective on why I hold the opinion that I do.

[00:10:36] And so you may think that you say, okay, I’m using this CSS and JS library, I’m using

[00:10:44] emotion and I like it better than styled components, or I like it better than using CSS monitors,

[00:10:50] or just regular CSS.

[00:10:52] And so you’ve just developed this opinion naturally, but then somebody’s going to come

[00:10:56] and ask you, if you try to teach it, somebody’s going to come and ask you, okay, so why?

[00:11:01] Why do you prefer it this way?

[00:11:03] It triggers this response in yourself of introspection where you’re thinking, you know what, I really

[00:11:09] need to come up with a reasonable argument for the way that I feel.

[00:11:14] And eventually you may end up changing your opinion or solidifying your opinion further,

[00:11:19] but it does cause you to dig into the implementation.

[00:11:22] You have some assumptions like, oh, well CSS and JS is faster because of X, Y, and Z.

[00:11:28] Well, we can do code splitting or whatever, but you have to dive in to make sure that

[00:11:32] you’re right.

[00:11:33] And if you just spout out falsehoods or things you don’t know, then you probably know that

[00:11:39] you’re doing that and you shouldn’t.

[00:11:41] You shouldn’t just spout out falsehoods.

[00:11:43] And so if you’re not certain of something, then you’re going to go do some additional

[00:11:48] research.

[00:11:49] And so it’s the questions that people ask you or the questions you think they might

[00:11:54] ask you is what makes teaching such a solidifier of knowledge.

[00:12:00] Yeah.

[00:12:01] Yeah.

[00:12:02] That last part is actually was my theory of why it works so well is you kind of assume

[00:12:09] the role of the person who’s trying to challenge what you know.

[00:12:17] So the questions of why is it that way, you may not have asked that to begin with.

[00:12:24] You may not even consider for a second time, why is it that I like this thing?

[00:12:30] Maybe it’s in the zeitgeist.

[00:12:31] Maybe you heard it from somebody that you trust, you know, there’s all of these on their

[00:12:35] face valid reasons, but they’re not mechanistically valid.

[00:12:39] You haven’t really investigated to determine that.

[00:12:42] And you end up kind of trusting the authority or whatever thing that you’re trusting.

[00:12:47] And if you go to teach it, you can’t teach it based on those reasons.

[00:12:52] You have to teach it based on something else.

[00:12:54] Yes.

[00:12:55] You have to try and take your subjective feelings about the thing, which are very possibly correct,

[00:13:01] but also possibly wrong.

[00:13:03] And you have to objectify them as much as you can and back them up with with true evidence.

[00:13:08] Like another thing, as I’m learning to teach React, I’m diving into APIs that React exposes

[00:13:16] and I’m thinking, OK, well, I need to teach them how to use this particular tool for optimizing

[00:13:21] performance of their component.

[00:13:23] And so, you know, react.memo will memoize the thing.

[00:13:25] Well, oh, I’m going to dive into this, learn as much as I can about it.

[00:13:30] And I end up learning stuff that I never actually put into practice myself because I never really

[00:13:34] needed it.

[00:13:35] So, like, you may think that you have a really good understanding of the tools that you’re

[00:13:39] using, but there are use cases that your tools support that you may never have had.

[00:13:46] And so you never really needed to dive into those.

[00:13:49] Or maybe you have the use case and you just don’t realize that they support that out of

[00:13:54] the box.

[00:13:55] And so you’re doing this work around or whatever.

[00:13:56] And so as you’re going through preparing to teach this stuff, you start exploring things

[00:14:02] deeper than you did when you were actually just building stuff.

[00:14:06] And you’ll come to realize that, oh, there’s actually a second argument I can pass to react.memo.

[00:14:11] And that’s called the comparator function.

[00:14:12] Now I have to understand that so I can go teach that or at least address questions that people

[00:14:17] ask me so I can say, hey, I never really needed this.

[00:14:20] Here’s what it does.

[00:14:21] You know, whatever, whatever the case may be.

[00:14:23] But as you’re preparing that information that you’re trying to share with other people,

[00:14:28] it forces you to dive a little deeper than you may have when you were actually building

[00:14:32] stuff.

[00:14:34] Today’s episode is sponsored by Linode.

[00:14:36] With Linode, you can simplify your infrastructure and cut your cloud bills in half with their

[00:14:40] virtual machines.

[00:14:41] You can develop, deploy and scale your modern applications faster and easier.

[00:14:46] Whether you’re developing a personal project or you’re managing larger workloads, you

[00:14:51] deserve simple, affordable and accessible cloud computing solutions.

[00:14:55] You can get started on Linode today with a hundred dollars in free credit.

[00:14:58] A hundred dollars goes a long way on Linode, by the way, a hundred dollars in free credit

[00:15:03] for listeners of Developer Tea.

[00:15:05] You can find all the details at Linode.com slash Developer Tea.

[00:15:08] Linode has data centers around the world with the same simple and consistent pricing regardless

[00:15:14] of your location.

[00:15:15] You can choose the data center nearest to you or you can choose a data center that is

[00:15:19] nearest to your customers or your users.

[00:15:23] You also receive 24-7, 365 human support.

[00:15:27] That’s all the time.

[00:15:28] In other words, you’re always going to have top level support.

[00:15:31] You’re going to have the same support as someone who has a top level, kind of the biggest account

[00:15:37] that Linode has.

[00:15:39] There’s no tiers.

[00:15:40] There’s no human support tiers.

[00:15:43] It gets that high level support from Linode, no handoffs, regardless of your plan size.

[00:15:48] You can choose shared and dedicated compute instances or you can use your hundred dollars

[00:15:52] in credit on S3 compatible object storage, managed Kubernetes and more.

[00:15:58] If it runs on Linux, it just so happens that it runs on Linode.

[00:16:02] Head over to Linode.com slash Developer Tea and click create free account.

[00:16:08] That’s a button.

[00:16:09] Click the create free account button to get started and get that hundred dollars of credit.

[00:16:14] Thanks again to Linode for sponsoring today’s episode of Developer Tea.

[00:16:19] I think it’s almost religiously accepted that problems are our best teachers as engineers.

[00:16:26] Often we do learn so much from the practical problems that we face, but I think it was,

[00:16:33] of course it was, a Paul Graham essay on Lisp.

[00:16:37] We talked about why Lisp was a more powerful language.

[00:16:42] Of course, he’s very opinionated because he uses Lisp, but he says it empowers something

[00:16:47] that other languages don’t at a fundamental level in the sense that it’s not that other

[00:16:53] languages do it worse, it’s that they don’t do it at all.

[00:16:56] It’s this new tool that you wouldn’t even know that you could use if you were using

[00:17:01] other languages, but if you’re using Lisp, it’s just kind of second hand or second nature

[00:17:06] rather.

[00:17:07] It’s very interesting because you wouldn’t know that just from solving a problem.

[00:17:11] You could probably solve the same problem with two totally different tool sets and imagine

[00:17:18] that you’ve learned the same thing, but you may not have learned the same thing.

[00:17:22] It seems like there is some other approach to go and just look at the tool set itself

[00:17:29] as kind of an observational exercise rather than saying, okay, I’m going to go and pick

[00:17:33] up the tool that I need when I need it.

[00:17:35] Yeah, and you know, I don’t want to downplay the benefit of practicality and actually building

[00:17:42] stuff.

[00:17:43] I have this talk that I actually just gave, and it might be on YouTube by now, I’m not

[00:17:47] sure, it was at React Summit, and it’s called Consume, Build, Teach, and that is my process

[00:17:54] for learning anything.

[00:17:56] The basic idea is you consume information so that you know what’s available, what’s

[00:18:00] possible, what tools are there, and get a basic understanding of the problems that they

[00:18:05] solve.

[00:18:06] Then you go and build something so that you can face problems and use these tools to solve

[00:18:10] those problems and get an idea of how these tools work.

[00:18:15] Then you go and teach the things that you learned, which will trigger you diving deeper

[00:18:19] into those tools than you may have when you were solving the problem.

[00:18:24] That’s really the recipe for true learning.

[00:18:27] Yeah, it’s interesting because there’s this, obviously there’s this connected relationship

[00:18:34] between teaching and learning, and you certainly seem to be a scholar on the subject of learning

[00:18:42] and teaching, so I’m interested to know, what is one of the things that people most often

[00:18:47] get wrong about the process of learning itself?

[00:18:51] Not learning anything specific, but the process of learning.

[00:18:55] So, I have a couple of thoughts about this, but they basically boil down to thinking that

[00:19:03] learning is a passive experience.

[00:19:07] I guess people who get stuck in the consumption side of the equation, so they consume things,

[00:19:13] they never really build anything, and if they do, they don’t teach the things that they’ve

[00:19:17] learned.

[00:19:19] And so, without all three of those steps, you’re not really going to get a solid understanding

[00:19:25] of the information that you have in your head.

[00:19:28] So, I see this very often where people will sit back on their recliner, flip on the Chromecast

[00:19:35] and watch a four-hour or maybe a 40-hour course on Udemy or something, and by the end of it,

[00:19:44] they think that they’ve learned what they watch, but they really didn’t.

[00:19:49] You won’t have that information at hand.

[00:19:51] Now, there is benefit to doing this.

[00:19:53] You will know that, oh, I remember that this was a problem that they had in that video

[00:19:58] and they used something to solve it and it was something like this.

[00:20:02] So, then you can go reference it later.

[00:20:04] So, there’s something happening there, but it’s not learning.

[00:20:08] It’s just cataloging of information.

[00:20:12] And our brains are pretty amazing, but they’re also really great at garbage collection.

[00:20:18] And so, if you don’t try to reference that catalog item, then you’re going to forget

[00:20:24] it in the future, not too distant future anyway.

[00:20:27] So, it’s not really true learning.

[00:20:29] So, yeah, just sitting back and passively watching material or whatever, reading blog

[00:20:33] posts.

[00:20:34] Another thing that I see that’s related to this is tutorial purgatory, where you just

[00:20:39] buy a course or you find a blog post and you go through the tutorial, you do exactly what

[00:20:44] they did, and you just keep doing this over and over again and you never actually build

[00:20:48] something of your own.

[00:20:49] This happens a lot, too, and you will not learn stuff just rehashing what other people

[00:20:54] are doing.

[00:20:57] And this is actually something that I specifically combat in epicreact.dev, where most teaching

[00:21:04] material…

[00:21:05] Actually, I’ll stop right there and I can talk about my strategy on epicreact.dev, but

[00:21:11] I’ll go ahead and stop because I can talk a lot.

[00:21:16] Well, I do want to get into it and perhaps this will actually open us up into that, but

[00:21:23] I want to ask you a question that I like to ask all my guests.

[00:21:30] What do you wish more people would ask you about?

[00:21:33] What is something you wish more people would ask you about?

[00:21:35] I don’t know.

[00:21:40] I get so many questions, a ridiculous amount of questions, because I try to be really accessible

[00:21:45] to people.

[00:21:46] In fact, I’ve started doing office hours, so twice every week I’ll give an hour of my

[00:21:53] time to just answer people’s questions, and that way I can kind of answer a bunch of things.

[00:21:59] So I get questions about a lot of stuff.

[00:22:02] Yeah, I don’t know.

[00:22:05] I think, see, stuff that comes to mind is like, how can I help you with what you’re

[00:22:12] doing?

[00:22:13] But I actually get that a lot and it’s hard to accept, or I always accept people’s help.

[00:22:22] This is a bit tangential, but I’ll just mention it because I think there are some interesting

[00:22:26] takeaways.

[00:22:27] So, when somebody comes to me and says, hey, I want to help you do something.

[00:22:31] I just want to help you with your open source or with your blog or something.

[00:22:35] So I’ll say, okay, well, here’s a thing that I want done.

[00:22:38] I need X finished, and so they’ll start working on it, but they lose steam, and the reason

[00:22:43] that you lose steam on something like that is because you’re not really actually invested

[00:22:47] in this.

[00:22:50] This does work out sometimes, but I need this pull request, I need this thing worked on.

[00:22:56] It doesn’t end up playing out very well most of the time because it’s not your own problem

[00:23:02] that you’re solving.

[00:23:04] I realize that was not at all what you were asking about, but that was just something

[00:23:08] that came to mind.

[00:23:10] Don’t try to solve other people’s problems.

[00:23:11] Try to solve your own problems, and if you don’t think you have problems, you do.

[00:23:16] Just hold your breath a little bit longer and you’ll find out that you do have a problem,

[00:23:22] right?

[00:23:23] Yeah, yeah.

[00:23:24] You have problems, and just asking other people for the problems that they have and trying

[00:23:29] to solve theirs.

[00:23:31] That’s what building a product is, right, and making a startup, but you’re much more

[00:23:35] effective when you have felt the pain that you’re trying to solve, so anyway, that’s

[00:23:40] not related.

[00:23:41] I’m not sure what questions I want people to ask me about.

[00:23:46] It’s a hard one to answer, especially for someone like you, who you probably are getting

[00:23:51] a lot of questions about things that you do like to talk about, and perhaps questions

[00:23:55] that you’ve answered a hundred times.

[00:23:58] You’ve mentioned this before on React Podcasts, where you have kind of preformed answers in

[00:24:03] the form of a blog post for these kinds of questions, but I guess the underlying concept

[00:24:11] there is, what is a topic that is really kind of, that you have a lot of energy to talk

[00:24:17] about whenever it comes up?

[00:24:19] That’s really kind of the thrust of the question.

[00:24:22] Yeah, I don’t know why, but testing is always something that gets me excited.

[00:24:27] I can talk forever about testing.

[00:24:29] I honestly, like I said, I don’t know why.

[00:24:33] It seems like such a dull topic, but I can talk about it forever.

[00:24:37] I’m also, like anything that’s on Epic React.dev, all of those workshops, I could talk about

[00:24:42] those for a long time, so React is something that gets me really excited.

[00:24:47] Yeah, I don’t know, I mean, there’s non-tech things.

[00:24:50] I get really excited about the future of energy, battery and stuff, solar, and I’m

[00:25:00] super bullish on autonomous vehicles.

[00:25:02] I have a Tesla, it’s amazing.

[00:25:05] I could talk a little bit about artificial intelligence and its impact on software.

[00:25:12] I’m not super well-versed in it, but it’s a topic that gets me interested in what our

[00:25:18] future looks like in the next 10 years or so.

[00:25:20] So yeah, those are a couple of things that I kind of enjoy talking about.

[00:25:24] Yeah, I think actually when you got your Tesla, I think you mentioned it on Twitter, and it

[00:25:29] was around the same time that I got my Tesla.

[00:25:31] So we must have had some pretty similar experiences since then of the process of acclimating to

[00:25:39] that kind of autonomous vehicle.

[00:25:42] It is definitely an experience.

[00:25:44] Yeah, it changes you, man.

[00:25:47] Well, I do want to talk about testing, and I want to talk about it.

[00:25:51] Maybe we can actually frame it in the lens of something like looking at Tesla, right?

[00:26:00] Obviously, we’re not talking about testing front-end components necessarily with Tesla,

[00:26:06] but we can think about the importance of a test in terms of its consequence.

[00:26:16] I certainly hope that we have a lot of tests that are backing our experience when we’re

[00:26:24] turning on the navigation mode on our Teslas, right?

[00:26:28] Because the consequences are huge there, but I’m curious about what you think about this.

[00:26:33] How do you think about coverage?

[00:26:35] I know you have the testing trophy.

[00:26:37] It’s something people can, if they’re listening to this, probably know about.

[00:26:40] We can talk about that a little bit, but how do you think about the importance of coverage

[00:26:44] on, let’s say, an area of your codebase that is dealing with trivial things, not so important,

[00:26:53] versus areas that are much more important, like payment pathways and that kind of thing?

[00:26:59] Yeah, I have a blog post about pretty much any subject you could ask me about testing.

[00:27:06] I’ve written about this a lot.

[00:27:07] I need to write a book.

[00:27:10] My thoughts on testing coverage are…

[00:27:15] You framed it really well.

[00:27:16] Not every line of code matters as much as the next.

[00:27:20] This line of code has something to do with the settings page for admins only.

[00:27:27] Maybe that’s important that they can change their display name or something.

[00:27:32] We want them to be able to do that, but then this other line of code over here is what

[00:27:36] controls the car’s ability to turn left.

[00:27:42] That’s a pretty important line of code.

[00:27:44] The problem with code coverage is that that metric doesn’t give you any insight into how

[00:27:49] important that code is at all.

[00:27:52] It’s just a metric.

[00:27:53] You can have 100% code coverage on that settings page and 0% code coverage on self-driving.

[00:28:00] That’s not a good thing.

[00:28:02] I don’t take too much stock in the coverage report itself.

[00:28:09] Our tools do have the ability to say, okay, this area of the codebase needs to have this

[00:28:14] percent of coverage and this area of the codebase, we don’t care as much.

[00:28:18] I would recommend configuring things that way.

[00:28:24] The biggest challenge is you never really get a sense out of these automated tools of

[00:28:30] how confident you actually are that you can ship your software.

[00:28:35] Even if you were to have 100% code coverage, that’s not going to tell you that you’re confident

[00:28:39] in shipping your software either.

[00:28:41] What I typically try to think about when I’m testing a codebase is, how do I think about

[00:28:47] the use cases that I support and how much use case coverage do I have?

[00:28:52] That’s what I focus on when I’m thinking about testing a codebase.

[00:28:56] The only use for the code coverage report is just to remind me of use cases that I’m

[00:29:02] not considering in my tests yet.

[00:29:05] I don’t look at code coverage and see lines of code.

[00:29:08] I look at code coverage and interpret that to be use cases that I’m missing.

[00:29:13] That’s what I try to cover.

[00:29:14] It’s impossible to really quantify, but that’s what I think about when I’m testing.

[00:29:18] Yeah, it’s tough because we don’t have ways of … I’m sure there are ways, there’s probably

[00:29:24] entire libraries to do this, but marking the severity level of a particular method.

[00:29:32] How do you know that that’s a really important one and that it should be covered twice?

[00:29:37] That’s a difficult thing.

[00:29:39] You have to have experience with the codebase in the average codebase.

[00:29:43] Like I said, I do think they probably have some kind of meta-marker decorators or something

[00:29:49] like that to say, hey, this particular method, this one’s really on the critical

[00:29:54] pathway.

[00:29:55] Don’t mess with this unless you really know what you’re doing or unless you are certainly

[00:30:01] covering it well with tests.

[00:30:04] It’s an interesting problem to solve.

[00:30:07] I’m interested to know also if we’re talking about testing and we’re talking about practical

[00:30:14] building of software, it’s very … I would say it’s easy to come up with a project.

[00:30:22] Like you said, in tutorial … what did you call it, tutorial purgatory?

[00:30:29] It’s easy to come up with a pet project to write for a tutorial and it’s very clear what

[00:30:35] the test should be.

[00:30:37] You can see the use cases.

[00:30:39] It’s all on a perfect spreadsheet.

[00:30:41] That’s easy, but when it comes to practical problems or there’s crossover or there’s dependencies

[00:30:46] outside of your project or there’s things that are outside of your control, maybe there’s

[00:30:52] some legacy code you’re dealing with, how do you navigate those kinds of problems?

[00:30:59] Do you have any kind of mental models for decision making in those areas when things

[00:31:04] get more complicated than just tutorial code?

[00:31:07] Yeah, and this is one of the reasons why tutorial purgatory is such a problem because you don’t

[00:31:13] face unexpected problems often.

[00:31:16] You will sometimes, but everything’s really well laid out for you and you typically don’t

[00:31:21] have to make these kinds of decisions.

[00:31:24] So when I’m thinking about adding tests to an existing code base or something, I actually

[00:31:29] do have a blog post, I think that’s titled that, but I basically … I kind of take a

[00:31:37] survey of the application itself and I think about what use cases are really important

[00:31:43] that I should not break.

[00:31:45] So maybe it’s an e-commerce site.

[00:31:47] I really want to make sure that checkout button works.

[00:31:50] Now you wouldn’t be able to enter in your credit card and do the checkout, enter in

[00:31:58] your home address and everything, do the checkout every single time you want to release.

[00:32:03] That could cost a lot if you’re selling boats or something.

[00:32:08] So you will need to set up some tooling around that to make sure you’re not actually making

[00:32:13] a purchase of a boat and there are strategies that I can teach you on testingjavascript.com

[00:32:18] on how to skip that portion so you’re not actually buying boats every time.

[00:32:23] But that’s where I start when I’m thinking about adding tests to a code base is like

[00:32:29] what part of this code base would be really, really bad if it broke?

[00:32:33] And that’s where I’m going to start and if you’ve already feel really confident with

[00:32:37] your automated test suite that you’re covering those use cases, then you can move down to

[00:32:42] the next tier of like, this would be pretty inconvenient.

[00:32:45] I would have to get up in the middle of the night if there was a problem with this or

[00:32:48] maybe this would be the first thing I’d have to fix in the morning or whatever.

[00:32:53] You really prioritize testing just like you do prioritizing writing any of your software.

[00:32:58] You say, I could either write this feature or I could write this test for an existing

[00:33:04] feature.

[00:33:05] Which one is more important right now?

[00:33:06] Well, I mean, customers want the feature but customers also don’t want things to break.

[00:33:12] So you do a risk analysis and then you just make you prioritize things.

[00:33:16] I actually have a blog post about that too.

[00:33:18] So, yeah.

[00:33:23] A huge thank you to Kent C. Dodds for joining me on today’s episode and the next episode

[00:33:29] of Developer T. Kent is an excellent teacher.

[00:33:32] I encourage you to go and check out the work that he’s doing, especially Epic React.

[00:33:36] If you are interested in being a React developer, head over to epicreact.dev.

[00:33:43] Thank you to today’s sponsor, Linode.

[00:33:45] Linode is going to give you $100 in credit as a listener of this show for creating a

[00:33:50] free account.

[00:33:51] Head over to linode.com slash developer T to get started with that $100 in credit today.

[00:33:58] Thanks so much for listening to this episode of Developer T. This episode and every other

[00:34:03] episode of this show up to this point is available on spec.fm.

[00:34:08] Head over to spec.fm to find show notes and other shows that you may enjoy as an engineer.

[00:34:15] This show would not be possible without you as the listeners sharing it with other people

[00:34:20] that you know will appreciate the show.

[00:34:23] There are a lot of places you can share this.

[00:34:25] Of course, you can share it directly with people you know or you can broadcast it out

[00:34:29] on something like Twitter.

[00:34:31] All of that sharing counts.

[00:34:33] It’s so important that we get the word out about Developer T so we can continue to reach

[00:34:39] engineers that care about these ideas, that actually want to grow in their careers.

[00:34:44] You are the way that we do that.

[00:34:46] Thank you so much for sharing this show.

[00:34:48] This episode was produced by Sarah Jackson.

[00:34:50] My name is Jonathan Cottrell and until next time, enjoy your T.

Visão de gráfico