#050 - How to write cleaner, more maintainable code

If you can do something with a colleague, a collaborator, or anything, that's a good start. If you want to commit to maybe something small, but something that will be public, that you might contribute to the community. That really, for me, was a big game changer. Hello, and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back, everybody, to the Pibytes podcast, episode number 50. Number 50. And for that occasion, we have a very special guest, Marty Heru. Did I pronounce that? Well, welcome to the show. Perfect. That's. No, that's perfect. Marty Heru is good. Thank you for inviting me. How are you doing? I'm good. It's been busy, and it's been probably almost a year now since we did PDM together. So that was good. Lots has happened, lots of development and stuff. But, yeah, I'm very good. So thank you for inviting me here. Happy to be here. Yeah. So, everybody listening? Marty was with us in the PDM pie bytes developer mindset program, build some open source data related projects, and boosted his skills. And these days, not only is he constantly improving his python and developer skills, he's also teaching it. And so we decided to have him on the show and pick his brain about what he has been learning and doing. Yeah. Yeah. So, basically, where I work, I'm a researcher at a neuroscience research institute. And being a bit more senior now, there's PhD students and some early postdocs, and I want to expose as many people as I can to coding as it's a skill for the future if they don't already have it. But also, we're not computer scientists, we're not developers by training. We just figure it out. And so it's taken me a lot longer than other people to get where I'm at. And I just would like to give these people the shortcuts that I learned and the headaches just. I kind of persist despite my failures, which is kind of possibly a good thing. I don't know. But it's gotten me to this point. Whereas other people, once they hit those, the roadblocks of the obstacles or a few failures, they might just say, ah, this isn't for me. But if they could just get over that hump and put the pieces together. And so that's kind of a bit of a role that I've wanted to play in the past. It just wasn't this inertia. And so it just so happened that lockdown kind. And also, I have to say, there's two other people that have kind of come along that are able junior people that can code quite well and that have been good students. And so I just put it to them saying, I can't lead this thing, but I'm happy to teach as much as you want me to, but if you organize it, I can see there's a nice cluster of people. So if you want to do this as a challenge, I think it would be a great thing for everybody. So we took it on board, did kind of a boot camp in January. It went for six weeks. We kind of developed a curriculum just to get people in with the basics of Python. And then from there, now we've just been rolling on with a rotating schedule. And sometimes it's a very junior person who presents. Sometimes it's a bit more senior, sometimes it's myself. And yeah, from what I'm told, the feedback has been really good. We keep a confluence site. We kind of have an idea section, we do code reviews and. Yeah, and it's. Yeah, it's a really nice culture that we've created that way. That's cool, man. I really love that. Especially, I think it was just last week I was saying that, you know, I actually put a tweet out on Twitter or something like that where I said, if the culture's not fantastic, build the culture that you want. And I know before you did this, you know, when you were still in PDM, you didn't have that essence of growth and community and building there. So really happy to hear that that's what you've been able to implement now. So with all of that said and done, I think you have a few tips you want to share with everyone. Do you want to run through some of your best practices? Yeah, definitely. Well, I don't know if. I mean, my best practices might not be the best ones, but if we think about it, there are just lessons learned. And sometimes I even heard about them, but I didn't get it until really somewhat major failures, I guess, but so if you oftentimes you can't tell when it's very good code, when you're a junior developer or something, just learning, it could be actually really good, but because you just know, you don't. I didn't understand it. I didn't realize that it was actually really well structured, well named, well organized. And so I didn't catch on to what those lessons were to be learned until later on when I kind of had to go back to my own code. It was quite messy, poorly structured, and so a few of the basic ones, obviously. At first, it was a bit of an eye opener about just when Michael Kennedy was describing his function names and his variable names. And I'm like, you're allowed to do that. Make them really long and clear like that. I just, you know, I was, you know, in science, sometimes it's quite mathy, and you kind of always have to have. I always thought they had to be short in like three letters, and they had to be, you know, I was just like, oh, no, no, you can make it long. That's cool. So if you make very clear function names, variable names, and when you go through that exercise of naming them, if you have trouble naming them, that's normally a sign right there that maybe this thing is doing too much, and therefore it's already a, can I refactor this? Can I make it into two small clear blocks that do something? And then I can name that same thing with. If this thing is a container with seven things, maybe it's a bit better if I split it up into a theme. And why that's important at the time. It's. So that's the, you know, also possibly because I'm older as well now. I just, I'm not as arrogant as I used to be. I'm like, oh, I'll remember this for the rest of my life. I know this code so clear, and now I know for a fact, I can say, oh, in a week from now, I will not remember this. And so that coding for yourself in the future is so, again, it fell on deaf ears at first, possibly because I didn't code enough. I was coding like spurts, and then I would stop and then almost never come back, though, now that I've got things that I go back to, a lot more that I reuse and packages and some code as well that I reuse, it's come to bite me when I didn't do that. So now it's something that I really value and don't be afraid to do it, I guess, is another lesson. This refactoring thing, it's actually not just move on, it's take a pause the next day, rather than moving on, go back over your code. This is what I do for scientific writing. I don't just move on to the next bit. Oftentimes I start my writing by re tweaking and editing what I've already written, it helps smooth it over. It makes sure that I understand where I'm going. And with the code it's the same thing if you can spend that extra bit of time refactoring. And I guess with that comes the safety of refactoring, is how can you do that? And that was the huge eye opener of tests. I've spoken about this a little bit before and it's now my thing that I tell all these junior people that are coming along, these PhD students and postdocs, that tests are not just there to make it look good, that you're doing good coding. It actually brings a lot of things that are positive to you as a coder in terms of confidence and certainty, and it actually makes you think differently about your own code. Um, and so the refactoring always scared me. Um, I've had a lot of, um, you know, anger towards my monitor, I'll have to say. Um, when I used to make a change and then it would break my code and I could never figure out where. And it was just horrible. Um, and so this kind of sanity that comes from having tests, um, for those people who are interested in kind of implementing that again, it's, it's do it to the extent that gives you the sanity that you need for your own code. And so whereas I first heard it, I thought everything had to be covered and had to be, you know, super complicated. It's not that again. But that comes with a bit of practice and maybe not, you know, going at it full bore. You just got to figure out what works for me. So those are really good practices. Can I go on or. I got a few more. By all means. Sorry. You got you. Yeah, go ahead. Yeah, I was going to say this. There's a bit of discipline involved with doing that. I can definitely see that it's easy just to slack off and have your variable names as x or your functions as main one or whatever. How did you make that a habit? And that's a good question. And I'll have to blame Bob for this one. It was in a good way. Is that before it was always about the output, the end result for us. So it's always about get the result in a figure or a number that you would give to your supervisor that you'd put in a paper. And that was the ultimate goal. When I joined PDM, my goal was very different. It was to, I want to make, if possible, a package or two to kind of make more reusable some of the things I built that I thought could be useful to other people, and even if it's just locally to the students I work with and a few other researchers, that was good enough for me. Learning that practice was going to be valuable. And instantly that changed. How that discipline came about is that I had to now face up to Bob every week. And I knew that there was another pair of eyes, kind eyes. I knew he was going to be somewhat gentle, and so that was a good thing. But just that. So knowing that Bob was going to be looking at it, trying to understand it, that changed how I did things because obviously I knew that he wasn't doing science in my area. So therefore I'm like, well, I need to make this clear to somebody. And generally when I write my science, I try to write it for my dad. So he's not a scientist, but he's well read. And so I figured if I can get my dad to understand what I'm writing, that's already anybody else who knows more, well, then they're going to understand it easily. So the same thing with the code is basically not make it local jargon for my field. I had stuff to learn, obviously. So that was number one. But then also there's going to be the. It'll be out there now, right. Other eyes will start to, if they're interested, they're going to come and actually open up my repo. They might click around. And it's a bit of showing in science, usually you don't do that. You don't show your code, you don't make it available because it's where all your hidden sins are versus now it's kind of out there. So it's kind of like you have to think about it twice and you have to. So that it was really, that it was having that other person thinking about another person that this would be shared with or, but eventually, maybe even the public, that's what's it really changed. And now even when I code smaller things, it's kind of stuck with me now. And so it's a habit. So if you can do something with a colleague, a collaborator or anything, that's a good start. If you want to commit to maybe something small, but something that will be public, that you might contribute to the community. That really for me was a big game changer. Yeah. It's all accountability. That's really good to hear and that it was. Bob, thanks for the perspective. Those are kind eyes. Kind eyes. Yeah. Oh, great job. Have to compliment you on that because true, the theme of your code, the designs, the spike, and all that jargon I was not familiar with. But you made it understandable by good structuring of your code, doc strings, naming things in a meaningful way. So yeah, that was really cool experience. Yeah. I think, you know, I just want to call out there, Marty, what you said was you write it for your dad, that, you know, it's not just, and not just the what you write in your documentation, but the fact that you could write your code in such a way. So that's something we don't often think about. We often think about, okay, if we're trying to communicate an idea, concept, something theoretical, we can all find ways of normalizing the language so that say, as they always say, make it so a 7th grader can read it, or a seven year old or whatever it is. Right. But I often don't even consider that with my code. Right. So that's a really, really great tip. I really like that it should be readable by people who aren't in your field, who don't know your field of expertise, but can at least follow it. I think that's cool. Yeah. And I think in science, I mean I don't personally use the Jupyter notebooks all that much, but in science what I think they're useful for is it's not just the fact that you can interact with it and maybe share it with colleagues who don't code themselves. For me, what I like it is that people who don't code, if it's done well, should be able to just read the function names, the variables and the outputs. Maybe they don't understand the things that are unique to python, or even just how do you do loops and those things? It doesn't matter, but they should at least be able to say, ok, it seems like they're doing this, there's this thing that they're saying that they're looping over, and then there's an output with this given name that seems to fit with what I would expect. So that kind of, even though they can't code, they could still probably follow the logic, which is what's important. So I think it opens it up to people. So it's true, my dad wouldn't be able to understand all the details, but with doc strings that are written for a genuine beginner and then thinking through the structure, that's another thing that was really insightful as well, is when you click, when you're not a developer and you're just looking around on GitHub and finding some repositories. I used to think my, they're so disorganized. Why do they have all these MD files in their main folder? I'm like, this is intimidating. And so many of them have all caps. I'm like, what's this business? But then you realize that that's just how it is. And there's a culture, but also there's a reason for it that it's built that way. And as you go through the lifespan of a project, those files get generated naturally at the right time. And by the end of it, you have a lot of them, but they make sense. And so it's not like you should just copy somebody else's repo and say, I need all these things. It's more about, well, early on you do this, later on you do that. Okay, I'm about to make it public. I do want people to contribute, so maybe I'll have, like, a contribution one, and maybe, oh, I need a license. And it just comes very naturally. But learning about that by experience, I think, is very different to just taking a book and saying, oh, this is how you properly organize and structure your code. It kind of, again, it's that thing of, um, practice. But with a genuine project is a very different thing than just working through, you know, some, some exercise in a book or something. So the, the having somebody there, also somebody to finding that person. Um, I have to say that before it was a bit. Now I'm in that role where I'm a bit more the senior person. So people come to me and I kind of, I try to be a good mentor to them. Um, but I was missing that. I was missing somebody who really was just, you know, above me and could guide me with confidence that I'd be like, okay, I'm looking to this person for help. And so, you know, having you guys be that for me really helped and kind of gave me the confidence to just, in a sense, if I failed, at least you could guide me in the back rather than just falling apart and being like, ah, this is too hard, and I give up. So, yeah, finding another person to be a mentor and then after that, remembering that, you know, you can then be a mentor to somebody who's more junior to you. And it's a valuable experience. You learn a lot, it's not a tiny bit time consuming, but on the other hand, you actually gain so much and it actually feels really nice. Like, when I'm helping these individuals and we're doing and they're pushing me, I just said, oh, basically we could do this, pre commit things and that would be cool. But I'm like, I don't know, I've just heard about them. And then basically the person who's a postdoc, she's quite clever and wrote back a cool band name, pre commit hooks. And then, you know, 2 seconds later she told me all about it. Do this, this. I wrote a yaml file and now we're doing it. I'm like, wow, you know, whereas for me it just mentally it seemed like a big obstacle versus. She had a bit of time, just wasn't intimidated by at all. Just now we're doing it, I'm like, okay, pretty cool. So it's a give and take in those kind of relationships. Yeah, I love it. That's awesome. And yeah, that's how as a developer, you keep on learning the pre commit with black and isort, something I recently started doing, and it's a game changer. And I think that falls under the banner of clean code. Right. So going back to that a little bit, you already mentioned a few things like meaningful names and splitting functions into smaller ones so that you have that opportunity to name more pieces. Right? Yeah. What are some other favorite tips about how to make your code cleaner, more maintainable? I mean, I think the obvious one, but it's not obvious. I mean, copying and pasting and then just, you know, that's obviously copying code and duplicating code. But the subtlety of how often that kind of creeps into your code, the fact that you're kind of using the same logic. So drawing up your code is very a common expression, but the more subtle side of things is sometimes hard to catch with you. Bob, there's a few things that are just. And sometimes I just wish that, you know, well, pretty much I wish you just sat beside me and coded with me all the time, because there's just some cool things that are just, you don't know until you see it in somebody else's code or somebody suggests it. And so I can't name them off the top of my head, but there's python so powerful that everything is an object that basically you could just have a dictionary that's just got strings for the keys, and then the values are actually whole functions. And basically it's just that thought that I could just have this little thing at the top that's basically just going to be like, depending when I pass to this dictionary I'm going to use and call this function blew my mind and cleaned up the code tremendously. And made it more readable, because in the end, the people, and that's the level of the abstraction thing, started to make a lot more sense to me. So basically it's kind of like, well, I want people to, if they dive in to understand that first level and then they can probably follow to the second level, and at some point it's true, it's just going to become, I kind of want to hide that business. And if they have to go there, that's fine, but the abstraction level. So the important bit is actually taking the time to make sure that those higher levels and the interface, how people are going to use it, put a lot of time into that. So I remember, Bob, I said, wouldn't it be cool if we could chain along these signal processing steps by just doing a filter dot, mean remove dot, and then do these sequentially? And then pretty much by the next afternoon maybe you sent me a little thing, and then all of a sudden we were off to the races. And it was so cool how to do that. And so that was amazing. You taught me that one. I didn't teach you. I just, I told you what I wanted. I told you what I wanted. You found that, and all of a sudden you had some sort of pandas behavior where you're just chaining things and. Beautiful interface. I like what you say. Interface, right. Like it's how you want the user to interact with your software. It's like a car, right? We just want to know how to drive the car, but we're not necessarily interested in the mechanics. What's under the COVID Right. The engine, the motor. So, yeah. You have that opportunity with your code to hide all these non relevant details and have beautiful interfaces for users. Shout out, of course, to fastapi typer. The work Sebastian is doing there. Um, yeah, it's, it's a joy to use those libraries, but go look at the code. It's super complex, but you don't have to deal with that. Right. Yeah. And they spent time doing it that way and that's, they planned it that way. Request is a bit that way as well. Obviously. They, it's, it's thinking about the end, the end user. And it actually requires effort by the person at that time to set it up so that it will be easy. And I think that's the thing I never used to do. I was just so happy. I ran once without air. I stopped there. But there is no other time that you're going to understand your code better than right after you're done. So that is the best time to refactor. Don't wait six months from now and then realize, oh, it's going to take you so much time to get back into that code and you may not even understand it to the depth that you did. And so basically, when you understand it, is the time to just take that extra little bit and refactor it, clean it up, make it a better interface, and you'll thank yourself later for it. That's been a valuable lesson because if you just stop and move on and don't do that extra, and it's not much, but your brain tells you, I need to move on to the next thing, but it's totally worth the time you put in. It's a technical depth thing, right? Like if you don't refactor constantly, regularly, you're building up that depth and it will be increasingly difficult to maintain the solution, right? Oh, yeah. And then I guess historically, some things, people just wipe the slates clean and just say, I'll start. Which is actually what I did, to be honest. The one we wrote together, the spike to PI, I think we were on version three because the first ones work. But then when I had to change it or add stuff, I didn't have any tests and I couldn't really touch it or else it broke. So I just started over because then I wanted to learn about classes. Great. Did that. But then again, it became very fragile and I couldn't do it. So then finally I was just like, okay, let's do this one last time. And, yeah, it stood the test of time. We're still using it. Haven't really had to touch much, but there's a few additions that we want to make. But it'll be very simple to do because of the way the extra effort and the design. So it's hard, though, when you're on your own and you're reading books or you're listening to podcasts, to go from that level to, I'm going to do this. So there's obviously finding a mentor, finding somebody who can help, and then if you can devote yourself to something like PDM. For me, that was. It was a gift to myself, really. It was kind of like, well, it was a bit of a lockdown thing. It was a. I'm not sure I want to up this skill because I really enjoy the coding side of things, but how do I do that? And so basically I look to you guys and just say, okay, well, you know, this seems like it might work, and then the flexibility of it. And so, yeah, it's just if you can find the right people, you can make, you know, big jumps in your skills and your confidence, so. And build something complex. Right. Because the projects you took on were not necessarily easy. No. But again, you know, it's on my own, I would have never redone that on my own. Right. And so it's just having. It allowed me to have the confidence to go there. And every time I was just like, I don't know if I can do this. I don't know if I'm going to get this done. And then, you know, you wake up the next morning and somehow, you know, we do a lot of learning when we sleep, so it's important to get a good night's sleep and, yeah, you wake up the next day and all of a sudden you're walking somewhere and you're just like, ah, it just jumps into your head. And so once you start to enjoy it and you actually start thinking of solutions in ways. Yeah, I think once the. Like, these junior people, these PhD students that are learning, they're still struggling and I think they're learning the language, which is kind of a whole thing. The quirkiness of how do you write code? But then they're learning how to think in code and they're learning two things at the same time. But once you get the basics of python out of the way. Yeah. I think that you can start to enjoy it, and that's when things become fun. Yeah, nice. You're exactly right. But actually, before we. Before we wrap up, because you said a couple of things I want to just touch on for the people who don't know, you did mention dry. So do you want to elaborate what dry stands for and what it. What it means? I can't repeat myself. Sorry. Oh, well done. Marty's sharp today, man. He's on fire. Jeez. D r wise, don't repeat yourself. So, you know, and this is, you know, the best example is I would never open it again in my life. But my PhD code, I don't know. I had 34 tremor subjects. I had pretty much the exact same code copied and pasted 34 times with individual changes per person because of this and that. And so I just repeated. And then if I had something to change, a mistake, or I needed to just generate a new graph, 34 places, I had to change that. It was horrible. So, basically, if you can find a way to identify patterns that you're doing, take them out, make them a separate function and call that function, rather than just having that, because later on, if you. If there's a bug. It's going to be much harder to find. And also, if you need to just make a change, well, you'll be doing it in one spot. You won't have to try to find all the spots that you had similar patterns. So. Yep, that is one of the most valuable things I think I've learned over the years with code. I remember, I don't remember what I was building. I think it was way back when I was building some sort of a steam scraper or something. But whatever I was doing, I needed to open a connection to, I don't know, an API. I don't remember what it was, to be honest, but I just remember having, I think about six or seven with statements throughout my code at every time it had to talk to the. No, it was to open a database. Every time it had to talk to the database, I opened it and closed it. And I used that code across about six or seven different functions. And so if I change the database path, I thought I was hacking by making the database path a variable at the top. Oh yeah, I only have to change it at the top now and then. It's good. But yeah, I learned better than that. But it's such a simple thing to do, it's almost natural to do it as you write your code to just go, oh yeah, I've used that before. I'm just going to copy and paste here as opposed to trying to think of it more like a resource that you call on whenever you need it. So, yeah, I just wanted to touch on that because, I don't know, just in case people didn't know what dry meant. And look, just as we do wrap up, you mentioned the python packages that you built through PDM. Do you want to tell everyone just a little bit about them, what they called and what they do briefly? Yeah, sure. One's called Spike two PI. There's a commercial software out there called Spike two which runs these data acquisition boards that we collect our signals on. And I just needed to get the data out and analyzed. And historically we've done it in Matlab. And now that I've moved to Python, I wanted to have a nice interface that provided me with most of the tools that I would use, generate graphs, almost pandas, like where basically you can just say data plot, and then it would give me a plot of it. I can do all these processings. And so we built that and it's been used, I don't know, I'd probably say about five studies at least by now. And, yeah, it's worked well. And the other one's called pliffy, which is simply, there's this new trend to make plots of differences and to do that's actually not the simplest thing. And more statistical packages are doing it. But when I started doing these plots, there was nothing around really, that made it definitely in python, nothing easy. And it's been something that's kind of been bothering me in a sense of, ah, I wish I I had it just more automated that I could just share with students to use and also maybe with others who might be struggling like I was. So I made that package and I have actually a new one that's up on pypi. It's less polished, not as much documentation, but it's part of kind of on the blog that we run, me and Joanna DeYoung, we have this blog that we run kind of just in a sense, our own learnings in scientific computing. I've been learning a lot about markdown and pandocs and how do you generate documents? Because there is kind of like this. I have an allergy to a lot of things, actually, Excel is one of them. And now word more and more, I just rather not use it. So I really like markdown and pandocs, and just to simplify that process to generate a scientific paper, I said, well, why don't we just make this a package? It's very small, it doesn't do all that much behind the scenes, but if you don't know pandocs, it's a whole new thing versus it just simplifies the pipeline there. So, interestingly, I would have never been able to even conceive that. And I was like, oh, I have to remember how to do all that setup, PI stuff, blah, blah, blah. No, it didn't take me long at all. And then basically with confidence, I remember the first time Bob said, you could just go ahead and push that to PI, PI tomorrow if you like. And I was just like, oh, my God, this is to the world. This time it was fine. I just published it and it was much less stressful. And so, yeah, so again, it's that thing of, now I feel I can contribute, and even if it's not going to be picked up by many people, it helps the group that I work with, and it has a bit of usefulness for a few people. That's great. And if not for, you know, locally, it still helps us a lot. So, pretty cool. Love it how you keep building new tools and, well, once you start doing it, yeah, well, you see the tools rather than before. It was the tasks and move on. Now it's like, oh, I'm doing this, I'm doing this. Let's make it into a tool that I don't have to do this again. Right. To reapply it. And so it's, you know, I think it's a progression in my, in my learning as well. So awesome. Well, thanks so much for sharing all this wisdom and pieces of valuable insight. To wrap it up. Do you have a final shout out? And where can people find you online? Get in touch with you, I guess. Artinheroo. One word, I think is Haru Martin. You guys will put it in the show notes, I'm sure. Yeah. Perfect. Because I'm on Twitter a little bit sporadically, and then my professional life takes over, and then I kind of fall off. But I do post a little bit. If not, it's just the blog that we run that that's a nice place to kind of see our activities. And so that's scientifically sound.org. And if not, basically, you can find me on the Internet at my workplace. We're on a research gate, which is where you kind of advertise, kind of like a LinkedIn for researchers. LinkedIn as well. I'm on, but yeah. And a shout out. I'm a bit disappointed. I saw there was a trend towards, what book are you reading? And I was so prepared. I was a bit stressed and, like, what am I going to talk about? And I didn't get the question, but that's okay. Okay. You can still do it. You can still do it. Perfect. I didn't think you could read, so that's. But that's cool. I'm kidding. I only read in French. Thanks. Oh, right. Only reads code. J'e translate for you. And so I recommended this one to Bob. I can't remember. I just thought of Bob when I saw this book. And it's just, if people don't know about it, it's just a simple book. It's called how to take smart notes. And it sounds like every other university, high school book that you might give. That's just, like, a bit silly. But this stuff is gold. It's based on this humanities researcher from, like, the forties who's in Germany, and he created this technique called Zettelkassen, and they're basically Zettels, which are these little cards. And he had 40,000 or more of them all organized. He created this amazing system, and it's for anybody who's doing work that's nonfiction, could be used for fiction as well, probably, but nonfiction, so for research, it's great. But even people who are working in code and education, it's just mind boggling how, when I started to read, I'm like, this is exactly what I need. I've been so learning and then moving on, but then kind of, what do you do with that learning that you do? And so if anybody's kind of into that, wanting to just have a second brain, that's just not just like an agenda and what am I doing right now but, like, almost like a life's work, but, you know, just gradually you can implement it. And so, yeah, there's a few tools out there. A lot of people are blogging about it. There's some videos, but Zettelkasten are just. It's the thing that I discovered this year that I had to put a pause on it just a little bit. But now that my vim skills, thanks to Bob's little tutorial that he gave me, I'm really up on the Vim skills. And there's a vim Zettelkasten that uses Vim Wiki, and I'm just in love now. So that's going to be a bit of my holiday stuff, just getting that to work and implementing it, but, yeah, so anybody who's out there that is interested in that, it's a good find. That's cool, man. I'm going to order it right now because I get sucked at note taking. Envious. That sounds wicked. He takes such good notes. There's our Christmas presents to each other. Bob, you buy it for yourself, I'll buy it for myself. First. Christmas presents have to be productivity tools, of course. Exactly. And Marty's pain, so. Of course. Of course. No, thanks, man. That's. That's great. I'm glad you shared that. Sorry, we actually didn't even think to ask you the question. Totally forgot. No, no, that's okay. And I'm not going to edit this out. We just. We just fly. We built. We build the plane as we fly it here. So we roll. Yeah. No, no, it's perfect. No, you guys are. Thank you for giving me the opportunity to chat, but really, it's also just the act of chatting is, you know, again, it makes me realize how far I've come. It's made me reflect a bit more on my, how I've transitioned, but yet I'm still learning. So I'm in this kind of mentor but mentee role right in the middle, and so. Yeah, no, it's. It's it's a good experience to, you know, to talk with you guys and it's always just nice to talk to you guys, period. But the theme of it made me think a bit. A bit about stuff. So. Yeah, so hopefully it's been useful to some of your listeners and, yeah, if anybody has any questions, comments, happy to be they reach out. Thanks, man. I think you're the first person to say it's nice to talk to us. So I appreciate that. Great present for our 50th episode. So on that note, I will say thank you so much for joining us. We really appreciate it, Bob. I'll also say thank you. 50 episodes. I'm happy that, Marty, you were here to join us for this. I can't believe we're at 50. Number 50. This is yesterday, right? Yeah, yeah. Started last year. Yeah. Last November, December, something like that. Eleven months in the making. Yeah, yeah. So not just the two of you, but a very special thank you to everyone who is listening and comes back week to week to, you know, listen to Bob and I ramble on about whatever we feel like. But we do appreciate you all and just all the feedback we get, the support we've received, so many emails and tweets and messages from people you completely unexpected to. So we just appreciate everyone's support. And as always, if there's anything you want us to cover, any topics to talk about, we're always happy to accommodate. I second that. Cannot add anything to it. Just stealing my words. Yeah, Bob wrote that before and I just. No, I'm kidding. No, we appreciate you and thanks for listening and, yeah, of course, the best ideas always come from you, so reach out, let us know. And of course, thank you so much, Marty, for coming on today and sharing all your experience. Oh, thank you. And congratulations to you guys. It's a big feat with you guys done. And as the from the community side of, we thank you. It's quite useful and, yeah, enjoy listening. We hope you enjoyed this episode. To hear more from us, go to Pybite, France. That is Pibit es friends and receive a free gift just for being a friend of the show. And to join our thriving slack community of python programmers, go to Pibytes community. That's pibit es forward slash community. We hope to see you there and catch you in the next episode.