Hey, everybody. My name is Daniel, and I like rocks. I'm a design system leader at Personia and something that I do like that is also a bit nerdy is math. I like math. There's many ways to solve a problem. One way to build it in an API is to make it with props. The next possible way could be composable components. Which one is better? Senior engineer answer would be, well, it depends. Props are really good with TypeScript. On the other hand, composition... You could have other types of components. You could create other types and put them and still work. Let's say I want to wrap it in a tooltip. You can see a bit of the differences in approach. This is a masonry layout. What kind of strategies can I use as an engineer for making my own decisions? One that I know is this one called YACNI. Over time, this creates tech debt. If you make a little bit of effort and make this reusable, it can go a long way in terms of API. And then the special situation that you want to handle just handling outside. At some point in my career, I was using a lot of YACNI and I started to work at Shopify in an open source project and I started to care about the APIs that I released because they are supposed to enable people to do the things they want to do and if it doesn't happen, then it's really sad. It's the same with design systems. If you make an API that is not good, there's a cost to it. How can I make good APIs? Let's see some of the big ones. TC39, they are the group that's actually creating the new JavaScript APIs. I made my own process that I call iterative component design where I try to figure out what is good enough for a release before putting it out. The step one is to prototype. And this is, again, doing Yagni. I think you can have better APIs if you follow a proper process. Second step, I usually write an RFC. When you do this, you realize what parts of your API sound really weird to explain. And the final step here is to share. Sharing is difficult because sometimes we have pride as developers and we don't want to take feedback and we just want to release immediately. But the problem with not getting feedback is that when you're working with a problem, you're unable to see objectively anymore. Sharing is good. All the APIs, there's never a state of nirvana for APIs. There's always feeling like something is not right, something is broken here. All my time working, I felt that we never got there and probably we will never. So all you can do is probably enjoy the process of creating APIs. That's my final advice. Thank you.