You could also do. Just pick one way that seems right at the time. Spend a week on it. If it's not work, if it's not working, it'll refactor to the other, or even throw it away, go the other option. There's a lot of people kind of stuck. And I think embracing the idea of refactoring. Maybe not in the traditional by hand effect of Martin Fowler's original book, but we have tools that do a lot of this automatically or almost right click and ask it to. What are your thoughts? I definitely think people should at least catch the zen of it if not go through the book because the tools will take care of it. Yeah, you still want to know the concepts here. The different techniques has already highlighted the extract method, for example, grouping, comes into enums we have mentioned before. So a lot of actually what we've spoken about so far can be found in this book as well, right? And I think overall the goal of refactoring is to keep that technical depth in check, right? So avoid suffer a rot, they also say. And yeah, as you start to add more code and cover more scenarios and the always changing requirements inevitably what happens. You kind of need to learn. You thought it was one thing, but as you got further into it, you're like, you know, that part's actually that's where the problem is. I didn't think so. But now I know because that's where it's hard, right? As you go. That's a good point. But the people who are stuck, I don't think they internalize that the only way to know where you're going to get stuck further down the road is to go down the road. You can't think about it very well. There are a couple of interesting comments here. With respect to guarding clauses, Alvaro says, you could go and put a search statement at the beginning of functions to indicate some of the assumptions that could be disabled and production and give nice errors on high price. So I test rather. Yeah? Possible. What do you think, bob? Yeah, it starts our grade, but yeah, that's happy that you highlight the caveat that they can be disabled. So you can not always rely on them. I definitely see a place for asserts. And of course, you use them in python all the time to assert different ways your function performs. Yeah. I use most me asserts in python. But I can definitely see a place for this scenario that albero highlights. And then Brandon Natalia has a very realistic problem that people run into is I worked a lot of places where they don't give you the time to do the refactoring and make things better. And so it just builds up until it becomes not ideal as his second comment here implies. That's a good point. That is a real problem. And I'll tell you how I solved it. Bob and maybe we're getting short on time, but you could tell me real quick. How you solved it? For me, when my managers and folks would say, Michael, what is your estimate for how long this is going to take? If I thought I was going to take 5 hours, but maybe I would need to do an hour or two over refactoring. This feature took 7 hours. Do you want it done? It's going to take 7 hours. Because if I'm going to do it, I'm going to do it right because I'm going to have to work on it afterwards. I know it's just going to get worse if I. So I wouldn't exactly lie to them, but I would include the time to make it right, not just make it work. As part of my estimate. Yeah, maybe even double it, right? Because there's the initial version and there's the testing. There's the documentation. There are bug fixes. There are inevitably are requirement changes in the spread meetings. So 5 hours might just be that initial draft almost, but maybe it should then be ten hours, yeah. Yeah, perhaps. But whatever it is, clean code should be part of the deliverable. In my opinion. And it should be part of the estimate. Estimate times three plus two weeks. That's a nice one. Exactly. It is a good one. Very good. All right. Well, we're getting short on time here. Let me do so I want to do some of this kind of different bump. Because I think this is actually, let me share a different thing here. I think that this is something people are going to have to start thinking about as well as maybe an option here. So what about asking AI assistance? Things like Google co-pilot or chat GOP. There might be some cases where people say, here's my code. Hey, could you make it better? So for example, let's do this to close out the show. Okay, bob. Sure. How can we write clean code in python? I'm going to ask you, we have already already covered this. Are you sharing those? Hold on, I thought so. I did, I forgot to add stream. So I'm going to ask chat CP here. And what else does it say? So I gave it all of your tips. And I said, we already discussed that. What else can we do? Paste in the article, as well? No, I didn't give it the article. Just the headings. So it says you can document your code. Keep it simple, which it didn't understand. Follow pep 8. This is an interesting one. Exceptions are for error handling. So anyway, I just thought it might be kind of fun to think about could we ask these things to help us and improve our code? I don't know if you played with any of this, but it could be fine. I have not yet. That's Julian's department. He's giggling. Eking out over the tool, but I'm having on my high on my list to try it out because it's really mind-blowing but what this tool is doing. Yeah.