And there's a few different reasons why it's powerful. Number one is it's motivating. So when you're solving a real problem for you or for someone else and your code is making your life better or their life better, it's incredibly motivating. And when something is motivating, it means you're a lot more likely to do it. And you'll notice if you've been paying attention during this podcast, keep coming back to motivation. But I think motivation is incredibly powerful and important, especially when learning to code because as I mentioned, learning to code is hard. And so there's a lot of discouraging things that tend to be kind of baked in to the experience. So the more that you can find things that are motivating, the more likely you are to continue. And it's all about continuing. It's all about not quitting and not giving up. Aaron also talks about this a lot. But the longer you keep going, the more likely you are to actually acquire the skills. And so I think this is an underrated but very important aspect of learning to code in general and also building projects. So I think ultimately the best project is a project that you're excited to work on. But the question is how to start. And this question also comes up a lot with students. My answer to this is to start small with what's called an MVP. That stands for minimum viable product in tech. And the idea behind an MVP is that you're starting with the smallest possible scope to accomplish whatever the objective is or to provide value. And so the opposite of this would be to be really ambitious, which I don't recommend. I'm thinking now of this time I helped out with a hackathon at Duke and a student came out to me and they basically were asking a question where they wanted to know how to re-implement a version of Uber and kind of tweak it for a specific use case. And I thought, whoa, let's slow down here. Uber is of course a huge company. It's publicly traded now. They have thousands of engineers. But I think it's easy to look at an app and kind of think to yourself that, oh, this would be simple enough, right? And I think if engineers are doing a good job, a complex app looks simple on the front end. But the reality behind a lot of the apps we use every day is that they are very, very complex. And so I think it is potentially over-ambitious to think, I'm just going to implement a version of some app that I know.