Kent C. Dodds (00:00):
Hello friends. This is your friend, Kent C. Dodds, and I'm excited to be joined by my friend, Josh Comeau. Say hi, Josh.

Josh Comeau (00:06):
Hello. Hi everyone.

Kent C. Dodds (00:08):
I asked you to say, "Hi, Josh," but that's okay. Close enough. This is a running joke that I have for this whole season actually. Every guest I'm doing this to. It's probably too much, but we're going to keep going with it. Actually, any of you who went through Epic React, Josh was a guest on the Epic React Podcast. It was a great conversation there. And when I was gearing up for season four of Chats with Kent, I was excited to talk with Josh again, because Josh you've been doing a lot since we talked at Epic React. And of course, like, there are plenty of other things beyond [Wimzy 00:00:46], which was a very interesting conversation as well. But there are plenty of other things that I wanted to chat with you about. And so I'm excited to have the opportunity, but before we get too far into that, I'd love for my friends to get to know you. So can you intro yourself to us a little bit.

Josh Comeau (01:03):
Definitely. Yeah. So my name is Josh. I'm a software developer. I've been doing this, depending on how you count for either seven or 15 years. I live in Montreal, Quebec, Canada. I mostly do front end work, but I will give myself the full stack label whenever I have to do any backend work. Yeah, I'm excited, I've been working, so most recently I worked for Gatsby, Gatsby JS the framework. I worked as a staff software engineer there, but these days I am setting out on my own and creating courses for developers.

Kent C. Dodds (01:30):
Thank you for the courses that you're creating too, that's great. And thank you for all the great work that you did it at Gatsby and just in general for the community, it's been awesome. And I really enjoy following you. And your blog is just a wealth of useful information and very well put together too. I'm currently redoing my website and the launch of this podcast, or this season is going to coincide hopefully with the relaunch of my site. And I am not a designer at all. So I have a designer and I said, I give him a list of others sites that I'm like, "I really like what they're doing here." And yours is one of the top on that list. Just like Josh has got some awesome stuff. We're going to throw in some like sound effects and stuff inspired by what you've done. So yeah, I think anybody who hasn't gone to your site should definitely go check it out.

Josh Comeau (02:23):
I appreciate that. And I'm glad this is a podcast and no one can see that I am blushing furiously.

Kent C. Dodds (02:29):
Well, I'm just happy to have you here for sure. So one of the really interesting things that you've been working on recently is helping JavaScript developers understand CSS. You have the CSS for JS devs. Can you tell us about what this project is? Give us like an idea of where the idea came from and yeah, what makes it, I guess, pretty unique? Because it is pretty unique. I'd love to have people get to know that.

Josh Comeau (03:01):
Yeah. Definitely. So CSS for JavaScript developers, it's an online course for folks who are familiar with my blog. One of the things I really like to do on my blog is use interactive examples, and that can take a few different forms. It can be a code editor that has like a live preview, but it can also just be like random widgets that I build. So I have an article on spring physics and it includes like these like weights that you can drag around and then watch the spring physics play out. I've always thought that this is a really great way to learn things. Like if you can play with it, right? There's like a tactile, you can experiment with something, it's just a great way to build an intuition. And of all the things that I thought I could teach, I thought CSS is the one A, that I think would benefit from this approach the most.
But B, is the thing that I feel most compelled to teach. And the reason for that is, I think about my own journey and how, I started writing CSS in 2007. So I've been doing it for a long time, but for the first like decade, I didn't actually know what I was doing. Like I knew enough to build stuff and certainly you can look at things that I built and they seem okay, but the CSS part always felt like a house of cards. Like you can do it, but it like might not actually hold up. And if something breaks, then it's like this complete panic because he realized that "my goodness, how on earth am I going to fix this thing now, when I barely understand how I built it in the first place." And I solved this problem over the course of years, by just trying to like learn little bits as I could.
So when I would solve a problem, I would try to figure out like, "why did this problem, like what was wrong in my mental model that led me to believe this property would behave in this way and how can I rectify that?" And as I started doing this, my experience with the language totally changed. Where it went from the most stressful part of what I was doing to just absolute joy, where you can like get into the flow and build stuff, and a lot of the whimsical ideas that I have are just me in the zone, just like cranking CSS out.
And it's not something I think I would be able to do if I didn't have that level of comfort. And just to be clear, CSS is still very surprising to me every night. Like it can still be surprising. So I don't want to make it seem like you'll never have any like head scratching moments, but I've reached a point now where I have the confidence that like, when I hit those moments, I can figure it out. And actually I get excited about those moments, because it's the opportunity to like put one more brick in the house of my mental model and get that much more acquainted with what's going on.

Kent C. Dodds (05:22):
And for anybody who needs evidence that you know what you're talking about, just go to Josh's website for real, you definitely know what you're talking about. And following you on Twitter is a pleasure as well, because you share tips and ideas on there too, I think it's awesome. And I love the idea of being able to like embed a little widgets to help people develop a mental model of things. There are several things you talked about that I want to touch on, but I think that's great. And with that, you're just using MDX, and sticking React components in there, right?

Josh Comeau (05:57):
Yeah. And I mean, I think MDX, people often ask and the same thing is true for my blog, my blog and my course platform both use the same stack, more or less. It really is just like, I want the ability to write Markdown. Like I don't want to have to use a CMS just because that seems like kind of cumbersome, but I also want to be able to just drop in. Like if I have an idea for something I don't want to have to be limited by like, "well, I have six or seven Markdown tags I can use," right? Like, should I make this a block quote?" Is that what like, no, like I want to be able to like build whatever random thing pops into my head and just do it as a React component, because that's like the tool that I am most familiar with. And it's just wonderful, it's so empowering to be able to have a thing in my mind, and I can just realize it by just writing whatever React component I need.

Kent C. Dodds (06:39):
Yeah, absolutely. I think that's just awesome. MDX is, at least for developers, it's a game changer. I don't know how excited regular content authors are about Markdown in general, I think they like Wizzy Wigs, but for me, I love Markdown and MDX just as super empowering. Anyway, so you also mentioned that when you would bump into like unexpected things that it was kind of frustrating and a head scratching. And what do you typically do when you run into like problems like that? Whether it's CSS or anything?

Josh Comeau (07:16):
Yeah, so the historical way that I have solved any kind of problem like that is you Google it. So you search in this is what I... Positioned relative, wrong position and you'll find a Stack Overflow thread and you'll scroll through six or seven things that don't apply, and then ah ha, you'll find the one that it's like, "Ah, this seems like it does what I want." So you copy paste it into your project, you refresh the page and behold, like the thing is now in the right spot. And so then you move on with your day and go onto maybe what is a more interesting problem. And next week you'll have the exact same problem and have to restart that process. So the way that I do it-

Kent C. Dodds (07:52):
You're just driving my experience with writing CSS. Well, to a T. That's exactly what I do.

Josh Comeau (07:58):
And I should say too, like I think that, at least for myself, I do this with everything, right? It's not just CSS, but like at least historically CSS was the thing I was most likely to do this for, because I struggled with a little bit with trying to like analyze why, but my working theory is that with JavaScript, right? Like if I had a same thing in JavaScript, I already have a pretty good mental model. And you build that mental model just by using JavaScript, right? Because if your JavaScript isn't right, you'll get an error message. And the error message will tell you, like, "expected" or "cannot call whatever on undefined." And so you have an idea. And so like just by using JavaScript, you build a better mental model. And so then when you have these cases where the thing doesn't do what you expect, it's like easier to fit one more brick into that house.
But with CSS, often there are entire mechanisms that you will just never encounter as someone writing CSS. I'll give you an example, with actually I mentioned it before, relative and absolute positioning. You spend a long time writing CSS and never really understand how position absolute works, because in order to understand how it works, you have to know about this thing called containing blocks. And this isn't something that you will run into as a developer writing the language, it's something that you'll find in the CSS specification, you'll see it occasionally in the MDN documentation, but it's the idea that every element has a block that contains it. And for most elements, it's the parent element. So if you have a paragraph in a div, that paragraph is contained by the div. When you use an absolutely positioned element, though, it doesn't follow the same rule, it's going to be contained by its closest ancestor that is not statically positioned.
And what I mean by that is the closest ancestor that has a position value set, so either relative or absolute. If it doesn't find one, then it's going to be positioned based on the viewport, which is why often you'll use position absolute to like put a modal right in the center of the screen, because you don't have to worry about its parent. And what are the things that befuddled me for a long time is sometimes it would do what I want, which is, it would put the thing based on the window. And other times, like I would set top zero and it would be anchored to some random point a third down the page. And like, you can run into that problem over and over again, and never actually realized that the thing that's happening is there is a parent. Maybe it's like the great grandparent, right? Three elements up the tree that has positioned relatives, and just doing that will change the behavior of this element. So I know I was going somewhere with this and I'm forgetting where that was.

Kent C. Dodds (10:20):
Oh no, you're good.

Josh Comeau (10:21):
Yeah. So, it's just a matter of like, "how do I solve these problems?" Yeah. So because it's so easy to keep running into the same problems without ever building. Like, it doesn't matter how long you'll spend writing CSS, you're never going to like somehow know what a containing block is. Like, maybe you'll figure out the mechanism with enough trial and error, but it's a lot more trouble than it is with JavaScript. So the way that I do that now, the solution that I have to this problem is when I hit those moments, where it's a little bit like, "Hey, this isn't what I expected." I'll like, take a moment and see if I can figure out what's going on. And sometimes that takes the form of, "let me just play with it." Like, "what if I change this value to some other or this property to some other value."
Other times I'll go straight to MDN and I'll say, "Okay, I'm looking at position absolute. Just tell me everything that, you know MDN, about position absolute." And often you'll find the answer there. I've also recently started going one level deeper and just looking at CSS specifications, which for a long time, I was just scared of doing this. Because it seemed like, and for context, CSS specifications are typically mainly I think used by browser vendors as a way for them to understand how to implement what should be the set of rules.
But they're actually like really accessible and really easy to read, and they're not at all as technically hairy as I expected. And just like taking that little bit of time when you run into the problem will save you so much time in the future because now like, next week when you have a similar experience, you don't have to spend time scratching your head and trying to figure it out. It's just like, "oh right, this is here because I have,"... You look at the elements pane and very quickly you're able to go through and figure out like, which element is the dastardly want and causing the thing that you don't expect.

Kent C. Dodds (12:00):
Yeah, absolutely. So instead of asking the question, "why in the world is this not centering on the entire page?" You're starting to ask the question. "Okay. So where's the container element?" You know what to look for. I think that's fantastic, and that was a great example. And yeah, I have read some specifications before and I think it does take some getting used to, but I agree, it's not as scary as you might think at first. There are definitely some like annotations or like symbols that they use and stuff that you kind of have to figure out. But yeah, this approach is why I'm really bad at hack night projects, because I typically get really frustrated when I don't understand why something is happening and often the work that I'm doing, I'm like, "Okay, so how am I going to teach this?"
And so I'm thinking about like my teaching approach, and if I don't understand it at a deep level, then I can't teach it. And so this means that I'm pretty slow to build stuff. I don't build stuff very fast. And especially when we're talking about CSS, because I am absolutely the guy who goes over, let's grab this Stack Overflow thing and we'll stick it here. And yeah, this is using like display flex, but then there's a grid element over there and who knows what's going on. But you're working on helping people figure this stuff out a little bit better. I'd love to hear about where CSS for JS developers came from, or the approach that you developed for it? Because it is pretty unique.
In some ways it resembles your blog posts, just like at a much higher level of quality, and more... What's really nice about courses like... Well, I was going to say courses like yours, but I don't know of anything that's quite like what you have. But what's nice about yours is that it's a path. Like it gives people a specific direction that's rather than just coding up something, grabbing a Stack Overflow thing here, and a tutorial there or whatever, but they actually have a specific direction that they're going progressively and incrementally learning more. So anyway, I need to stop talking and just let you tell us all about what this CSS for JS.dev thing is.

Josh Comeau (14:19):
Yeah. And actually I have two different, like axes, like two different perspectives, two different lenses. The first is just around, and we spoke a little bit about like how I use MDX. I would say there's like five media types. So there's like articles, which have these interactive elements like my blog, there's exercises, which are small kind of contained. Like, I give you a code playground and say, "okay, here's a screenshot and match this." Or like a, maybe a gift if there's motion involved, "match this thing." I have videos, which is something that is a little bit new for me. But I have so far over 75 videos and most them are like three or four minutes. So they're very quick. And I use videos kind of for two things. One, is to like, sometimes it's just helpful to be able to explain something like kind of face to face, even though there's only my face involved.
And other times it's like, for all the exercise solutions, it's just rather than have like a written description, it's just more helpful for me to show you how I would solve this exercise. Because there's all these little things that you'll pick up just like little idiosyncrasies that I think can be valuable. But the second to last thing is mini games. And this is something that I hope to do many more of, is just like ways to explore something through like a little game. And it's really more like a quiz than a game, but they do have interactive elements. So one of them has to do with margin collapses. And margin collapse is one of those really funky things where there's like seven or eight different rules that all interact in strange ways. So I just give you like blocks on the screen.
And the idea is you drag the block into where it should be based on what happens to the margin, and there's nested blocks. So it's like a fun way to like build that model. And then the fifth content type is workshops. And so every module ends in a workshop and these are larger, they're like exercises, but larger scale. And they're really meant to say, okay, we've gone over this module, right? This module might be about Flexbox or relative, like positioned layout, absolute relative positioning. Now let's like take those ideas and use them in a real world project where we can actually see.
Like, not totally real-world, they're still a little bit contrived, but definitely larger than you would find in like a small exercise. So all of those media types, I think serve two purposes. One, is that I can pick the media type that is best suited for the thing I want to explain. The other thing too though, I think that it's even more interesting is that it keeps it interesting. Like you're not just watching video after video, you're not just like coding, like exercise after exercise. By having that variety, you can make it more interesting and I hope make it easier to stay engaged for longer. All of what I just said was the first like axis, right? The lens that I wanted to look at this through. Goodness, what was the other lens? It might be good if-

Kent C. Dodds (16:49):
[inaudible 00:16:49] I'll give you a quick break, because I just want to mention a few things about that. And so the number one most important thing for me when I'm teaching is retention. Like if you don't remember what you learned, then the entire experience was a waste of time. So we've got to make sure that you remember stuff. And a huge part of retention has to do with interleaved practice and variability. If you're just doing the same thing over and over again, you're not going to retain it.
You're going to end up moving onto your real world project and be like, "wait, what?" And then you start using the material as reference material, which is fine because sometimes you need to do that. But if that's all that it's for, and then you may as well just have a list of MDN links, right? It's not much better than that. So the way that you've structured CSS for devs, and it sounds like were very intentional about this, but that outside of, or the result of it is just a huge amount of retention because of the variability and the interleave practice. Being able to use things in a real world setting, all of that just is just really helpful for retention. So I think it's just a phenomenal job on that.

Josh Comeau (18:09):
Yeah, interesting. That's a good way to look at it because I had been thinking largely in terms of attention. But I think the two are closely related, right? Like the thing that I was afraid of is people would buy the course, spend half an hour on it and get bored and go do something else. So my thing was just like, if I can keep you in this course, if I can make it interesting and engaging and entertaining, then you'll go through and you'll learn more. But it's true though, all of those things are all related to retention as well. And I remembered my other lens that I wanted to talk about. So I talked about like, just the structure of like the technology and the media types. The other thing is just like the like pedagogy of how is this structured and how is it laid out?
And I think this is one thing that's, I think relatively unique for my CSS course. And I had always wanted to do this, but I like went deeper and deeper into this rabbit hole of exploring CSS by its mechanics. So rather than just like, "here's a CSS property and here's what it does," which is I think how a lot of CSS resources work, right? Here's how display flex works, and now here's how the flex shorthand works, now here's how a line items work. I try to like say, "Okay, what is the actual like algorithm that is being used for layout and how do these properties fit into that?"
So what is the like browser actually doing? I think that's like a more like cohesive way to look at it because often properties interact in strange ways. And if you're just learning the properties, those interactions will be surprising and kind of they'll catch you off guard. You understand the mental model then that's like, if you understand that all of the properties are just inputs to some big function that we don't see. And then the output is whatever the layout is on the screen. If you understand that algorithm, then all of those strange interactions kind of make sense because it's just, you pieced together. Okay. So if the browsers like doing this, then this, then this, you can kind of work that in to your own mental model, yeah.

Kent C. Dodds (19:52):
Yeah. That makes a lot of sense. And I think that's especially important with CSS. For JavaScript, the only time you run into like properties impacting each other is if the code has been structured in such a way that everything's mutable or you've got a lot of global namespace stuff, but outside of that, which is not really any automatic JavaScript these days and more like, and the functional approach and things like you write some code over here and all that matters is this code over here. Like you see everything that's maybe you call a function, but, but you can see that relationship there. Whereas with CSS, you have to have a broader mental model. So that approach seems to work really well for CSS, especially. So, that's awesome. And I don't pretend to know every CSS course there is in the world, but I'm pretty sure that yours is very unique in that way.
Yeah. It's fantastic. Cool. So, I wanted to touch a little bit more on the way that you go about identifying problems, or digging deeper into problems. So you mentioned that like you run into a problem, you dive deep into MDN or something like that. What are some other resources? Like, let's say that what I'm working with, isn't a browser specification thing, but it's like a library and it's doing something unique or interesting or like interesting in not a good way, kind of like confusing and like maybe it's a part of a build tool or something. So it's not like just the output that I can debug in my browser, but now they're like weird things going on. Well, what's your typical approach for digging deeper into those sorts of problems, so that you can avoid running into the same problem over and over again?

Josh Comeau (21:41):
Can you give me an example of the kind of problem that you mean? Because I'm not entirely sure that I understand, like why that would be different from a website.

Kent C. Dodds (21:47):
Yeah. Well, so like I'm looking for resources, or where you typically dive deeper. So if you're using a library like React, for example, since we're both use React quite a bit, and you're rendering this component, but it's not resulting in what you expect, but it's not something that you could go look up on MBN, they don't really have react docs or anything. Maybe it's hidden in the React doc somewhere, or you just don't understand how you use effect works or something. Yeah. Where do you typically... Where's your first step to figuring out or digging deeper to understand what's going on with a library code or something like that?

Josh Comeau (22:33):
One more quick question, do you still mean in the context of CSS? Or is this just like-

Kent C. Dodds (22:37):
Oh no. Just like general?

Josh Comeau (22:39):
Okay.

Kent C. Dodds (22:39):
Just general- [crosstalk 00:22:40]

Josh Comeau (22:43):
That's the bit I was like,

Kent C. Dodds (22:43):
Yeah. good.

Josh Comeau (22:46):
I mean, I think that... So with a library that I don't understand, it's kind of the same process, where all first start by just seeing, can I work this out through experimentation? So I'm getting some weird error, but I don't understand, like, let me just poke at this and see if I can make sense of like... I mean, the one benefit in most things is that you have error messages. So that's a good starting place too, that's one of the things that's kind of missing from CSS. But yeah, I think generally it's kind of the same process of like, let's try to figure this out. If I can't figure it out in like a couple of minutes, then I'll start Googling and doing research.
If I don't like immediately find an answer for that, then I might consider asking on Stack Overflow. I haven't done that in quite a while. Twitter is also a great place, but if I have some like really obscure thing, then I'll just like, and granted, this helps because I have like people follow me on Twitter. So it probably wouldn't work so well if you're just getting started on Twitter. But even then, I remember years ago just like I would have 150 followers and I would still like ask and get the occasional person that would not know the answer, but would take someone that might, so it's a great way to like, especially because yeah, there are just like, sometimes you will. And I think there's even like a joke about this, that like you search for something and there's one result and it's from like 2008 and it's someone that has the exact same problem. And you're just stuck wondering like, "did this person ever figure this out?" They never followed up.

Kent C. Dodds (22:46):
Yeah.

Josh Comeau (24:03):
Yeah. I don't know that I have any great answer in terms of like additional processes that I have. It's all just kind of trial and error and hoping that I can eventually stumble on something that will give me the right answer.

Kent C. Dodds (24:15):
Yeah, absolutely. You need to, often I find it's useful to isolate the problem into like a code sandbox, or just a little local project. And do you ever like dive into the source code as well? Like on GitHub and try to understand what is happening there?

Josh Comeau (24:32):
Yeah, that's a great question. It depends on the thing. If the thing is React, then like if it's sufficiently complex, like React, I've done it a couple of times and haven't found it useful, and that's just a matter of like, I don't have the context for this. But if it's like, styled components is one example of a thing that is like small enough that it's like bite size enough that you don't spend your entire day just getting a sense of like, "how was this even structured?" If it's like some, like, I have a couple of packages myself that wrap other... I have a thing called use-sound, which is a React hook for sound. And like with things of that nature, and of course, it's weird that I mentioned my own. I just can't think of any other good examples right now.
You know, it's like the entire package is like three files and maybe like 300 lines of code. So it's not too daunting. Yeah. I mean, I think that's definitely a good approach, especially like one of the things that felt like a super power when I realized it is just realizing that all of your dependencies and your non modules folder, you can go into them and granted a lot of the times they will be minified and uglified and it'll be like harder to read, but I can still just throw a break point in there and just like poke around and see like, this function has five variables that are all single letters because it's been compressed. "What are all these variables holding?" Yeah. I think that, that's a great resource or a great strategy as well.

Kent C. Dodds (25:41):
Yeah. Yeah. Well, great. Awesome. Was there anything else that we didn't talk about, whether about CSS or anything else in general that you wanted to make sure we mentioned before we give people their homework?

Josh Comeau (25:53):
Yeah. I mean, I think that two things. One, is just like, I suspect a lot of people will wonder why should I learn CSS, right? And we talked a little bit about how it can make your future life easier. But I think a lot of people think, "well in the future, we're all just going to have component libraries that are going to come with all the CSS. Will I need to know this?" And my answer is always emphatically, yes. You do need to know this. I've worked at many companies. I've worked at Khan Academy, we had a really good component library. I worked at DigitalOcean, we had a pretty good one. I have never not had to write CSS. Because inevitably, you need a UI element that doesn't already exist as a component, or it has a component, but the design has some required tweaks.
And now you have to go into that component library and tweak the CSS. And that's especially challenging because maybe you have to find a way to like manage multiple possible behaviors. So I think it's always important to learn CSS. I think just like the return on investment. CSS is complicated. It will take you years to master it, but you can get really far in like five minutes a day. Like if you just like occasionally try and go a little bit deeper, I can't think of another language that offers the same kind of reward for that investment. The other thing I wanted to mention was CSS resources, because there are quite a few cool ones that I've found. One of them is just Firefox. Firefox has all these cool developer tools.
I use Chrome myself, but I always have Firefox open. One of the really cool things that Firefox does that I hope other browsers adopt, you know how some CSS properties don't do anything unless they're joined with another CSS property? So probably the most common example is z-index. If you just put z-index 5 on an element, it's not going to do anything because you have to have position relative or position absolute, or it has to be a flex child. Firefox will tell you. So if you put z-index 1 on something, you get this little white I icon, and when you mouse over, it'll say, "this property has no effect. Try adding position relative." And just like that little bit of diagnostic info, it's so useful because like, how do you, I guess you could Google it like z-index not working and you you'll probably come up with the answer, but often the dependencies are more implicit than that. Another example is if you put like margin top on an element that is inline and it might even be that you're doing it on like a span.
So you haven't even set the display property. It's just inherently this property doesn't work with this tag, and Firefox will tell you that. So that's really cool. Another, and this is a bit of a deep cut, because it's something that we only released recently that I don't think people know about. And granted, there's a bit of context here, which is stacking contexts, I wrote a blog post about them. But the browser doesn't really give you a way to understand what the stacking contexts are. And just very quickly a stacking context is a group of elements that are stacked, usually using something like z-index. But it's like one of those things that it's really hard to diagnose and someone I know, and hopefully can, can link this in the show notes, because I don't have the name of it offhand. It's a Chrome extension that will give you like this really, really nice way to explore stacking context and just whole classes of problems become trivial with this extension, so I will pass that along.

Kent C. Dodds (28:48):
That's all really awesome advice there. And actually I have blog posts about stacking contexts was mind blowing for me. Like I had no idea about any of this stuff. But it explains a lot on the whole z-index thing. And like, I definitely am guilty of just like, "well this is over this. So I'll just slap a z-index and hopefully," but Nope, it didn't work. I don't know why try the next thing on Stack Overflow. So yeah. Thank you for sharing all of that. Okay. So as we wrap up here, we do have homework for folks and this one's not specific to CSS, but I mean, for me, this is most likely going to be something that I end up doing with CSS. But the next time, as developers we're always running into things not working the way we expect them to.
So we're coding along, we're like, "okay, so then this we'll do that and this they'll do it." And then we pull it up into the browser and boom, it's not doing what we thought. So the next thing that happens to you eventually, you're going to figure out the solution hopefully. And once you do take about 10 minutes to dive in deeper to understand why it worked the way it did before and why your solution fixed it. Like Josh said, at the beginning, "often we just kind of, we grab the solution and we stick it in place and then we move on to the thing we want to actually work on." So don't do that. Just spend a couple of minutes to dive a little deeper and maybe you could write a blog post about it or something to kind of explain it to yourself in five months, or your coworkers or whatever. Anything to add to that, Josh?

Josh Comeau (30:20):
No, I think that's awesome. And I do think that this is general, right? Like you can do this for anything. But I think it's especially valuable for CSS because like we talked a little bit about earlier, you will learn things that are otherwise unincounterable. Like you'll never learn about stacking context just by using z-index. So that like five or 10 minutes of research will put a puzzle piece into place that will otherwise always be missing. So like with JavaScript with enough practice, I think those pieces fill in naturally, but with CSS especially, it's critical.

Kent C. Dodds (30:50):
Awesome. Hey, thanks so much, Josh. It was a pleasure to chat with you and thanks everybody for listening. We'll see you all in the next, oh actually, the next one is going to be about Josh or with Josh. So you can look forward to hearing Josh in our next one. We're going to talk about, well now I removed my notes. What are we talking about Josh?

Josh Comeau (31:07):
So we're going to talk about building a reputation and just kind of how like the community, the JavaScript community, and I guess programming communities more broadly can help you in your career.

Kent C. Dodds (31:15):
Awesome. Yeah. So look forward to that. It'll come up right next in your podcast player, if you're listening in order. And we'll see you all soon. Bye.

Josh Comeau (31:23):
bye.