 Jake, how do you feel about banks? I feel indifferent to banks. Okay, how about one they turned into a pub? Oh, that's progress. Yes. Do you know how to untar a file? No, I never remember. I see, I do. It's T-A-R-T-A-R. Dash and your arguments are X-Z-F. Okay. The way I have remembering this, and someone else taught me this, I think it's brilliant, is because you're untarring X-Z-F, X-Taxi files. It's perfect, right? You will never forget that now. No, I'm not going to forget that now. So I had to go and do some work on an older project of mine from some time ago. I'm so sorry. Right, exactly. I don't know if you've had this before where you come to some older code of your own and you're kind of looking through this project. Yes, and you have the Gandalf moment. I have no memory of this place. Exactly that. It just was like someone else had written it and they'd written it. Not very well. Like a wazik, mate. Yeah, it kind of made me feel that even on a project where I'm going to be the only contributor, or if I expect only me to be the only contributor, even then, maintainable code is so important. When I was at the BBC, we had a pattern which I really liked where before we even started on the implementation of a part of a library we were working on, we would first write the docs and we'd write them in line, which is kind of not entirely popular at the moment. But I still liked having the documentation really close to the code because when you were updating one, it reminded you to update the other. But the way we did it is if we were adding new functionality, we would write the docs first before any line of code that showed off the function signature, the arguments, what it returned. And that is the first thing we would code review. We would code review the documentation before any of the code. And one of the things that you would do as part of this is write examples of function usage. And it happened loads where as you were writing the examples, you're like, this isn't fit for purpose. Now I'm actually pretending to be a user of this function. This is actually really hard to use for the common stuff you use it for. Because it's not a particularly attractive part of coding, right? You're like, you know, I'd rather do the features. I'd rather do the new exciting thing than kind of make sure that, you know, me six months from now could read this code. Well, have you ever coded something in a way that you kind of step back from it and you think, ah, this is only four lines now. I'm very, very smart. Yeah. I've actually seen this a lot. And it really, you know, it really bugs me actually because it's like, I've got, you know, four functions that do broadly related things. So what I did instead is I made this one mega function. Mega, not in terms of its quality, but just in terms of, you know, how it sort of, it bakes all those four ideas down into one thing and then you call it four different ways. I've got one function that actually produces the other function. It's almost become self-aware. The code is now writing itself. I am so smart. In many cases, just doing it the simple way, which might be a few lines extra, it might even be slower, but it's only worth, like, removing the maintainability if the benefit is worth it. Like, if that's a hot function, if that's going to be called a lot and the performance benefit's worth it. Yeah, absolutely. This is micro-optimization in some form there and it's not worth doing otherwise. I sometimes find that when I'm reading code for Python projects, I find their code really, really easy to read, even though I know JavaScript a whole lot better than I know Python. Pep 8. Pep 8. Do you think as a community, as a JavaScript community, we need to just swallow our pride with all of these different, like, techniques of, like, writing JavaScript and just, even if it's not, even if it's the one we all a little bit hate, we just, we have our own Pep 8. I think what you're tapping into is actually the cultural requirement. It can't just be, you can't codify maintainable standards. It actually has to be something that's baked into the people that are working on the code that they want to keep the technical debt low. They want to make it easy for themselves and for other people and the people who join the team to actually be able to sort of contribute. And I think that's, it's a crucially important thing. Maintainable code is just a better way of doing it. To the heroes, or unsung heroes of maintainable code. Cheers.