Don't Solve Problems, Eliminate Them

Hello, everyone. Yes! My name is Kent C. Dodds, and I'm a software engineer, and I'm going to talk about how we should avoid solving problems and instead try to eliminate them.

But before we do that, I'd like to have everybody wake up. So please stand. We just had lunch. Your body is like, oh, it's time to sleep. No, it's not. It's time to stand up. Stand up. Come on, come on. Put your arms out in front of you like this and squat down and come back up. This is exercise, you know. We didn't have to do that when we were locked in our rooms.

So we're going to do 12 of these together, and I want you to count out loud. Ready? One, two. You're not counting. Three. There you go. Four. Five. Six. This is so great. Seven. Your legs are like, what are you doing? Nine. Ten. Is that 11? Should we start over? 12. No, just kidding. Stretch up as high as you can and stretch over and to the other side. All right.

Now, before you sit down, just introduce yourself to the person next to you and thank them for coming. And if you're online, you can talk to your cat. Thank you. For that.

Okay. First I just want to mention that I rewrote my site and relaunched it recently and it's really great and I want you to take a look. And in fact, I've even got the logs running right over here. So if you want to make these logs go nuts, go to KentCDONS.com right now and we'll see like crazy stuff. Please. No? All right. Fine. I have a little bug in the server, so that's good. Yeah, there we go. That's what I'm talking about.

So when I was building KentCDONS.com is when I started thinking about how we want to eliminate problems rather than solve them. And I'll get to that a little bit toward the end. So that's where the idea for this talk came from. My clicker's not working. It's mine. It's not theirs. It's my fault. So I will just use the keyboard.

So what this talk is, I'm going to talks about problems, solutions, and trade-offs and how solving is great, eliminating is better, and avoiding is even better if you can manage it. I'm not going to be giving code examples. This isn't a live coding thing. As much as I enjoy those talks, yeah, in fact, it's not even about code necessarily. It's more about life in general and problems. And yeah, not domain-specific. So I know that we're at a React conference, but this doesn't have a ton to do with React except toward the end where we try to apply it. So this is a problem tree.

You're not supposed to be able to see what's inside of those little squares. But the blue icon right here represents the core problem that you're trying to solve. So whatever the mission of your company is, that's what this core problem is. Or what the core goal is. And off of that, we have different problems that we need to deal with. And each one of those extra nodes is another solution. And sometimes the solutions that we develop lead to more problems. And so eventually we get to the terminal solution that doesn't have any problems that we care to solve. And these are way bigger in real life. If you were to try to map out all of the problems that your company has, or whatever it is in life, then yeah. You would have many. So here's a simplified version of a problem tree. And we're going to be referencing this a couple of times throughout this talk.

So first off, I think that it's important to acknowledge that you are a problem solver. That's part of why humanity is the dominant species on the planet, because we solve problems and we have, I guess, dominated the planet. But we're so good at it that we also become problem seekers. Where we're looking for problems to solve. And this, I have a bit of a story about this. And maybe you can relate to this.

So when the pandemic hit, my sister, who's a very accomplished violinist, saw all of her professional musician friends totally out of work, and they weren't sure what to do. And so she came to me and said, hey, can you build me an app that can help solve this problem? And I won't go into the details of it. But she basically needed me to build a Google calendar and Zoom in a single integrated thing. Not integrate those, but build them all. We always underestimate the amount of work these things will take. And she said she'd done tons of market research and looked at what solutions were out there and everything, and she felt like she was willing to hire somebody to work on this problem. And I told her, you know, like, maybe you need to actually just manually work through these tools and be the one facilitating what you're trying to do here, and she said, no, I just want to automate all of this stuff and scale it and everything. And I just said I just don't know. And so ultimately what she ended up doing was nothing. She decided she didn't want to invest into it. And I think that was a wise decision. One thing that I have learned is I've been living, I guess, is that it's way easier to solve a problem when you know what the problem is. And we kind of assume that we understand what the problem is on the outset, and so, like, we assume that we're going to need a ticketing system and we're going to need a calendaring system and a video chat thing, and we have all these assumptions. And maybe you do, but you don't know all the intricacies of what features those different things are going to need. And so, I suggest that you first feel the pain of the manual solution and then you solve those pains as they come. And so, problem avoidance is this. You avoid solving or avoid the problem all together by not creating the solution prematurely. And Elon Musk recently had an interview and I just really love this quote. He said, possibly the most common error of a smart engineer is to optimize the thing that should not exist. And I thought he was talking about me. So, it's better to avoid problems than to solve them. So, here's our problem tree again. If we're avoiding a problem, let's say that we want to avoid the problem in solution 1B here. And we just decide we're not going to solve it.

That's what problem avoidance is. You don't solve it. And here's the takeaway that I want you to come away from this talk. Often we get down in this problem tree and we get down to like one node. And we're working on this solution right here. And it is a beast of a solution. Like this problem right here is just super duper difficult. And as we're working through this solution, we're like, man, this is hard. And sometimes you might even say to yourself, if I'd known it was gonna be this hard, I never would've done it.

And so, that's the moment where you think, you know, do we really need to solve this problem at all? And often, you do. Like you're absolutely... This whole thing doesn't even work if we don't solve this problem. But maybe this whole thing doesn't need to exist either. And so, you can go up in the problem tree until you get to one solution that you're like, you know what? We don't actually need that. So, the users don't even use this feature very much. So, like, we can just get rid of this feature altogether. If I'd known how expensive it would be to solve this problem, I never would've added this feature in the first place.

So, re-evaluating our problem tree can save you a great deal of time and ultimately be better for your users, because every minute of every day that you spend, or, like, everything that you can do has the same currency, and that's your time. And every minute that you spend doing one thing is a minute that you can't spend doing another. And so, it's totally cool to just say, you know what? We're not gonna solve that problem, because we have other things to deal with right now. This is why I tell people that, hey, like, I don't test everything that I write. Lots of people think of me as a testing guy, like, 100% code coverage and test-driven development. That is not me. I see testing as a mechanism for automating code quality and confidence, but that's not the only thing that I'm doing. The code doesn't exist for itself, so you have to be practical about the sorts of things that you spend your time on. Problem avoidance is fantastic. I recommend it if you can avoid problems, but sometimes the house is on the cliff, I guess? I don't know how this happened, but I'm glad somebody was there to take a picture at least and maybe they dropped their camera and went and helped. I don't know, but sometimes you can't avoid the problem, so in this situation, before you try to solve the problem, see if you can eliminate it. I don't know, blow up the house. This is a bad metaphor, I guess.

So here's the reason. Solutions hold you captive to their maintenance forever. And I'll give one example in the real world. So here's an internal combustion engine, and there are a lot of problems that we've faced over 100 years that we've been working on internal combustion engines that have been solved in remarkable ways. So first off, we have exhaust. When you burn gas, there's exhaust, and that exhaust is not good for our lungs, and so we don't want it coming into the cabin, so we have all this piping going to shoot it into the back of the vehicle where certainly it will do no harm. That was sarcasm. So that's as far as we've gone on solving that problem. Stopping also, we have brake pads, they squeeze the disc brakes, or the discs, and we can stop the vehicle. And that's worked, except we also, those disc brakes don't just magically disappear and you have to replace them, right? That rubber is going into the air and we're all breathing it, but that's as far as we've gone to solving that problem. Cars will actually catch fire, like that's amazing that when you're literally burning stuff and exploding things to make you move that maybe it'll actually catch fire. But they've put a lot of work into avoiding this problem or kind of trying to solve this problem as much as possible. And then sustainability, well, this is the problem that we just decided we will not solve with internal combustion engines. It is not possible to make this sustainable. So what if we look at our problem tree and we say, you know what, this sustainability problem or the car fires or whatever else, this is just a really difficult problem to solve. Let's go up the problem tree and get all the way back up to mobility. Now of course you can ride bikes and you can jump on the subway or whatever, but at some point people need to have individual mobility. So how are we going to solve that problem? What if we totally changed the approach altogether? And this is the Tesla electric engine, this is the engine that powers the fastest mass production car in the world, the Tesla Model S. And here are the problems that they've pretty much eliminated. Exhaust is absolutely eliminated. There's no exhaust. Now people talk about the long tail pipe, but the fact is that eventually all of us are going to be powered off of sustainable energy so that long tail pipe is cut off. We have no exhaust problem, period. I do have a Tesla and my home is solar powered so I'm driving on sunshine and it's awesome. When we got the system turned on just last week, I started driving my car and singing, I'm driving on sunshine. It's just like, so, so, such a great victory. And then stopping, the cool thing about electric is that you can actually turn that kinetic energy into actual electrons and stick it back in the battery and so yes, while we do still have brake pads on electric vehicles, we probably never actually need to replace them because most of that energy is going back into the battery and so we haven't eliminated that problem altogether but we've drastically reduced the impact of that problem. So that's super awesome. Car fires, as far as, I know that like electric car fires get in the news a lot but as far as the data is concerned, you're 11 times less likely to have your car catch fire if it's a Tesla model or yeah, a Tesla. I don't know about the other manufacturers but the data I have seen is a Tesla.

That's pretty significant. And then sustainability, ultimately we can make this sustainable and that's like that should be the only reason that we do this. If if all the other things were fine, this is reason enough for us to make this change. And so like by going up the problem tree a little bit and saying, hey what if we don't actually need to solve this or what if this is too hard of a problem to solve and we go back up the problem tree a little bit and say, hey what if we change our approach, and now we have a new solution, so we haven't eliminated it, we haven't decided we're not going to solve this problem of personal mobility, we're just going to change it so that we have a smaller problem tree. Now certainly there are many problems with electric vehicles as well, but the problem tree is smaller and the problems are smaller and that's why this elimination is so great. Tesla is actually a really great case study for problem elimination so if you ever want to see the amazing things they're doing with manufacturing, it's really phenomenal, very interesting.

Okay, so let's talk about software now. In software, we have some examples, particularly in React, of problem elimination. So how many of you all have written class React components? Any React Create Class folks out there? Got a handful of you. Yeah, that was fun. Yeah, and then we got class components. And this screenshot here comes from Amelia Weittenberg's React hooks blog post which is very good. I recommend you take a look at it. But one of the big problems that we had with class components was code reuse. And you would have a single concern in your class component that would be spread between these three life-cycles. You would have your componentDidMount, componentDidUpdate, componentWillUnmount. If you wanted to subscribe to Firebase or you wanted to update the document title, you had to spread all of this stuff up in your component. And so reusing that was a little tricky. Did we use a higher-order component so that we could make a component that does all that stuff, and then we just pass our component to that so that we can accept that as props? Well, there were a lot of problems with that. You had namespacing issues, it was very difficult to type, and so we started doing render props. And those were fun. Really powerful. But then we have, like, these giant trees, or a pyramid of doom, trying to get all of these things composed. They just didn't compose very well. And so it worked, and it wasn't bad. Like I lived through that, and it was a good time. I had a lot of fun with that. But wouldn't it be great if we just didn't have the problem in the first place? So hooks came around and co-located all of the concern into a single bit of code. So it could be like a use date and use effect and a couple other things in there. But it could all be in this same snippet of code. So what do you do when you want to reuse code? You can create a function out of it, and you couldn't do that with our cost components because the concern was spread through multiple life cycle hooks. But with these hooks, you can just take that and stick it into another function. That was brilliant. It made an enormous impact on the ability for us to reuse code. It drastically reduced the amount of stuff I need to teach in my React components patterns workshop. Things became so much easier when we just went up the problem tree, decided, hey, what if we did things differently and then went down that direction.

Now, there are problems with making those sorts of migrations. We all felt the pain of having to move over to classes and, like, should we even bother all that? By the end of it all, we're much better off. And I'm really grateful to the React team for creating hooks. It's made my job a lot easier.

So now it's my favorite part, and I want to talk to you about Remix. How many of you have heard of Remix? How many of you who are raising your hands heard of it because I tweet about it nonstop? Yeah, so most of you. So yeah, I tweet about Remix nonstop because I love it. So full disclosure because people always want that. There has been a transaction between me and the Remix team, so I had to pay them money to access Remix. But that is not going to be the case. They say in a few weeks, Remix will be open source completely and free, and so you will be able to use Remix as well. So let me sufficiently hype you up about this. I don't have a ton of time to go through everything, but I want to just give you a high level because Remix is the reason that I started thinking about problem elimination in the first place.

So the first thing that Remix does that just makes it phenomenal is nested routing. One nice thing about this is you no longer have like a route that's like slash users, slash IDs, slash contacts or something. Now you have in that route file, whatever framework you're using, you probably have to render your layout route. And that will include your header and footer and everything. With Remix, you have nest routing. So each one of those is going to just be the component that cares about the part of the route that this part of the route URL cares about. That's really nice. But to take it even further, that's just like a nice developer experience sort of thing. But because of nested routing, Remix can do a lot of awesome optimizations as far as loading your data and validating the cache and loading the right data so it doesn't load more unnecessarily. That's a really cool thing, because Remix has nested routing built in.

Another thing that I love about Remix is the seamless client and server interaction. Just like Next has the Git server side props, you've also got a loader with Remix. But Remix does a really great job of making that connection very seamless, as I say here. So you've got a can be fully typed. You can go make all of your requests to database or GraphQL or whatever it is, and then all of that data is just available in your component and they have really nice declarative error handling and so as far as your component is concerned, the data is there and you never have to even worry about error states or loading states, because all of that is declaratively handled for you, so by the time it gets to your component, you just you don't use use use effect, maybe that's all I need to say, like whoo! Yeah, I don't use effect, all right, and you don't need a tool like React query, if you're not using remix, you should use React query, but if you are using remix, you don't need it because React query solves a big and awesome problem, thank you, tanner, for creating it and those who are maintaining it now, but wouldn't it be great if we didn't have the problem to begin with, and that's what remix gives us with its awesome client-server interaction.

The other thing I love about remix is that it's based on the web, so everything is fetch API stuff, even on the server, you have a request and a response, and if you need to learn something about that, you're not going to the remix docs, you're going to MDN to learn about how the web APIs work for that. And aside from the transferability of knowledge, you also get the fact that, because they're the web APIs, we can run this in a Cloudflare worker, or in a service worker, and Cloudflare workers are currently supported, service workers eventually, they'll support that.

And so just nailing that abstraction has opened a lot of really awesome opportunities with remix. And what's cool is that you don't really have to change any of your code. Now if you're going to work in certain environments, some of them like serverless, you can't connect to have a long connection to a database or something, but as far as the remix-specific code, none of that needs to change because it's all based on the web and remix smooths out everything for you. It's kind of like jQuery for the server. I've never said that before, but, yeah, kind of like that.

Other thing I love about remix is it's simple mutation. So all mutations in remix you have a form, so even like your delete button, the way we do this is we have the little trash icon. We have an on click handler that will do the request, to delete the item. With remix you use a very declarative here's my form, here's the delete icon, and you click that, that submits the form, and then remix takes care of all of making the request and what if I make another request and we're loading data and remix will cancel the right one, make sure everything is loading in order. Even if JavaScript fails to load, which that does happen sometimes, most people don't disable JavaScript but failing to load JavaScript does happen, or JavaScript that takes a while to load, which that happens even more, all of your mutations still work because you're using regular forms and they're doing regular posts or regular deletes and you'll end up with a full page refresh so it's not as awesome of an experience. But this is what we call progressive enhancement. And so your app still works even without JavaScript and it doesn't take a great deal of effort to make that happen, because it's just the way that it works.

And then also I just love the CSS story with Remix. Here's the big secret about how CSS works with Remix. It blows my mind how simple this is. So to get CSS on the page, you have a link tag and you point to the style sheet. All of us, we're using Webpack and bundling it all, or using styled components and having it part of our components, and it's really nice to have that co-location or whatever it is. But in every app that I've ever used, if you've got regular CSS, it's all going to be bundled and it's going to be available on every page. In Remix, each route can define the link tags that it wants to have active when that route is active, or wants to have on the page when the route is active. And when you navigate away from that page, then those link tags are removed. And so if I want to have some special CSS that's applied to only this particular route, then I can say, hey, here's the link tag for that. And I say, here's the CSS file that I want on this route. And when I navigate away, Remix removes the link tag. And that's it. That's the whole secret. But here's why it's so cool. It's because that when I'm in that CSS file, I know exactly which routes that CSS file is going to impact. And so normally at any other company that I've worked at, any other significant project that I've been at, any CSS file you were working in, or SaaS or whatever, you just knew that this CSS would apply to every single page. And so you were always worried about removing something, because something might break. You're developing, of course, you're looking at what's happening here.

And so you're worried that you might break something that you're not looking at. But with remix, you know exactly which pages this is going to be active on. And so you know exactly which ones to look at. And in practical terms, it's normally just on a single route. And so as you're developing it, you can make any change you want to the CSS, you look at the page, and if it looks the way that you want, then you know that your CSS file is good. And you don't have to worry about it impacting other pages on the rest of the app.

This is another great example of problem elimination. Eliminated the problem of unexpected CSS clashes. It's just phenomenal. All of the work that we've been doing for all of these years to try to make CSS easier for us to use, especially as React developers, with CSS and JS and CSS modules and everything in between has been to help us avoid CSS clashes and remix doesn't completely eliminate the problem. But it makes it predictable, and I love that about remix. Side note, just skip to the end and use tailwind for everything cause it's amazing. But it's really nice to know if I wanted some one-off CSS that I could add it to the single route and not worry about it impacting any other page. And I don't need any runtime or any funny extra build tools or anything. It's all just it just works and it's the web. It's fantastic.

There's so many more things I want to tell you about remix, but I just don't have the time so we're gonna wrap this up. And actually if you do want to know more about remix, I am more than happy to talk your ear off for the rest of the conference about it, and I've got a billion stickers that I got myself. So again, remix is not paying me for any of this stuff. I asked them, can I print stickers? They're like we can't send you stickers. I'll buy them myself. Because I am so jazzed about this framework. So a lot of you might be thinking, well, problem elimination sounds like choosing trade-offs. And yeah, that's what it is. That's what problem elimination is. So the idea behind problem elimination is to eliminate big problems in exchange for smaller ones. And the reason why this is talk-worthy for me is that I don't know about you, but when I'm involved in a problem, I am not thinking about whether or not that problem needs to be solved or if I can go back up the problem tree and rethink the problem back at the top. That's why Hooks was so phenomenally awesome was because we're all working, how can we solve this code-sharing problem down at the bottom of the problem tree? And the React team just went up a couple of levels and said, hey, you know what? Maybe we could just take a completely different approach. And it worked. Right? We all love it.

Most of us do. I do. So in conclusion, solving problems is great. Please keep solving problems. There's so many problems in the world, and I want to see you all being problem solvers. Eliminating problems is even better. Find different tradeoffs and take the thing that's easier. Avoiding problems is even better. So if you can't avoid the problem, then try to eliminate it by changing your approach, and only if that fails, then solve that problem.

One last thing before I go to my last slide, I forgot to introduce you all to Cody the So this is Cody, and that's people often ask me what's with the koala? So when people ask me that, I know they haven't been to my workshops, because Cody helps you go through my workshops, all the workshop material. So anyway, I felt bad having this random koala next to me, and I forgot to introduce him. So that's Cody. You can actually get your own stored at Epic React.dev and get your own, and it's adorable. Kids love it.

Thank you all very much. Thank you. Thank you, Mr. Kent C Dodds. Hot seat, please. Oh yes. Oh yes. We've got a lot to talk about. Only solutions though. No problems. Well, actually, one of our first questions was what's the story with the koala? So I guess we solved that. Oh, there you go, yeah. That's Cody. I didn't know you had a merch shop. Yeah. It's very exciting.

So they've got shirts and jackets, the most comfortable jacket that I've ever worn. In fact, quick story on the jacket, I got a jacket like it at React Rally a few years ago, and I tore it up really bad when I crashed on my one wheel. Like the entire shoulder was just ripped up. And I was so sad that I found – I asked the conference organizers where they got the jacket and I found the company, and I created it on my merch store so I could buy it. That's why it's on the merch store. Because I like the jacket so much. It's soft. It's super comfortable. We're going to have to check that out. Do you know if it ships to London? Yeah. I'm not sure how much it costs, but it's probably too much. You heard it here first, folks.

Sorry. All right. Adil asks, any remix workshops coming? Oh yeah. In fact, if you go to KentC.com slash workshops, you'll find I have two scheduled already, as well as a TypeScript with React workshop coming up. Incredible. Yeah. Fun stuff. All I'm going to be talking about for the next I don't know how long is remix. I'm going to teach you all how great remix is. Mac asks, how do you approach the sunk cost fallacy? At what stage would you say it's too late to eliminate the problem you're working on? I mean, it's never too late unless like the sunk cost fallacy is basically, oh we've sunk so much into this, we can't quit now, whatever. But if you just evaluate it right now as it is, the work I need to do to solve the problem and the benefit I get from that and the work I need to do to change my approach and the benefit I get from that, you just do the cost benefit analysis of that. Yeah. I wouldn't say that it's ever too late to solve a problem. It's just like, how are things now and let's go with the better direction. That makes sense.

When you eliminate a problem, how do you leverage the unknown? You don't know the problems you're going to face down the other path. Yeah. That's actually great. That's kind of my story with my sister, who is trying to solve the problem for musicians who are out of work. And this is where I say, do it manually first. Like, just go on forward and then just make sure that you're evaluating as you go and you realize, you know what, if I had known this, I never would have done it and I don't feel like it's worthwhile going forward, or whatever. That's good advice.

A little bit related to our previous speakers, from our last slot, how does Remix play with microfrontend approaches? So Remix is pretty new, so it's hard to say. And I have basically no experience with microfrontends in a practical sense, so I can't actually answer. But Remix in general is very abstractable. That's one of the things I like about it. So I am guessing it would actually be quite possible to make it play nicely, but nobody has done it yet. My website is literally the biggest deployment of Remix, and it's not small, but it's 27,000 lines of code, and it's the biggest one, so it's still pretty new. Kind of a popular one in a nutshell.

What is Remix? Remix is a framework to help you build better websites. It's comparable to Next. Server rendered. Do you think Remix will get rid of everything we learned so far? React, query, etc? Well, not everything. One of the things I love about React in particular, and Remix uses React to be clear, but one of the things I love about React in particular is that the better you get at React, the better you get at JavaScript. Yeah, I love that coming from other frameworks. With Remix, one of the things I love is that the better I get at Remix, the better I get at web development. Because it's based so much on the web platform. And so I think that all of the nice things that you've learned about the web platform with whatever framework you've been using, you bring all of that with you to Remix. And Remix will teach you more. Any of the other things... Yeah, you're not going to probably be using React Query with Remix. You could. There are potentially use cases for it. So yeah, any React Query specific thing that you know, that won't carry over, but it's not because you... There's a different approach or a different API you need to learn. It's because there is no API that you need to learn. And that's even better.

There's a couple of questions about comparing Remix to different things, like Next or Recoil. Do you have any rough thoughts on that? Yeah. So Next compares most of that. In an app that's like quote-unquote finished, not in the process of migrating, you wouldn't use them together. Recoil is a state management solution produced by Facebook to solve a very particular problem and you could absolutely have that problem when building an app with Remix. And so then you could use them together. But the typical CRUD application that you're building, you don't need a state management library certainly because Remix manages the server cache for you and everything else works nicely with context. It compares well. And then also another big one is Gatsby. Remix is server rendered and I know that Gatsby now can also do some server rendering as well. But, yeah, Remix takes a drastically different approach and I think that leads to a better user experience.

A lot of Remix questions. Remix is the best! I love it! Do you think it's ready for a wide scale production app? Well, they're not officially open source and there's technically no way to get access to it until they do become open source. Because they closed down new subscriptions and stuff. So if you want to work on it today, then yeah, no. But in the next couple weeks, then certainly. I think that it is definitely missing some things. I don't want to make it seem like it's the perfect solution for everything, especially now. But those things will come. I got excited about Remix when it was first released, in fact, even before. In fact, I bought the test subscription because I was so eager. And I accidentally bought a test subscription for a dollar. So I have two subscriptions to Remix, actually. But yeah, I knew from the very beginning that Remix was based on a really solid foundation. And that all of the holes that were in Remix at the time, and some holes that are still there, will easily be filled in because the abstraction layer that they're operating under.

And having worked on it now for your site, how do you feel it would integrate with perhaps a legacy code base? I think there are various approaches that you can take for integrating Remix. So, like, one thing you could say, let's start doing Remix for these routes, and then we'll just have some redirection there, and it will be, like, a separate app. That would be a really easy way to do it, but there are also ways ‑‑ I was talking with somebody recently about integrating their PHP rendering with Remix, and you could totally do that. Have PHP render some stuff. Remix will server render some stuff along with that and send all that HTML to the client, and that would be possible, too. So you've got a lot of flexibility.

Awesome. You heard it here first, folks. Before we switch to a couple questions about problem solving, Alex asks, is the stretch part of your daily stand‑up? No. I don't have daily stand‑up, because I work for myself and by myself, it's very lonely. But ‑‑ We're here for you, Ben. I got the air squats from Ben Ornstein. Years ago he gave a talk called how to talk to developers, back in 2013, I think, at RailsConf. And it was a phenomenal talk. I recommend it if you want to get better at talking to developers. And that was one thing that he did. And I, yeah, borrowed that from him. Wonderful. There you go. You should all give it a try. I get ‑‑ I've given almost a hundred talks now, and I get nervous before every one. Which makes you wonder, like, why do I even do this? But the air squats helped me loosen up a lot. So thank you for indulging me.

Let's talk about problems. Hastu asks, how do you identify a problem that needs eliminating without having gone through X iterations of solutions and associated problems before deciding we might need to rewind? Yeah. That's tricky. That's kind of related to the sunk cost problem. So this is where the term spike comes from. So like you time box a certain amount of time you're going to spend researching a certain solution or finding solutions to a problem. Yeah, sometimes this is why, like I think this is where funding can actually help the entrepreneurs where they're like we're not sure this is going to work but we think it will. So give us some money to let us try and there's risk involved in that. And so hopefully it does end up working or you learn enough to find another way to do it. And sort of related is do you have a set of criteria or heuristics that you use to evaluate a problem when deciding whether to tackle it or eliminate it? Not really, I typically I think it just needs to become a part of your regular routine where you just re-evaluate your problem space right now and think well, man, I worked really hard on that solution and I'm still not done with it and just think like take a few steps back, why do we have this problem? Well, because of this. Well, why do we have that problem? Because of that and just keep going backwards. Now, we're out of time for some of the questions, but a couple of things, first, any other pets coming up or will it only be Cody? Well, there are a lot of Emoji in my workshops, we have Marty the money bag, that one might be fun. Just like bags of money for you, but I don't have any plans for extras, Cody is my favorite. Right after this, Kent will have a speaker room for folks at home, you can join on spacial chat for folks here, if you want to keep chatting to Kent, follow him after this talk. Right after, we will also have the hybrid discussion room right in the discussion room. Thank you.