Talking about it was the best part about it, that we're here using Python because it is community centric. It's not the best technology. It's the second best technology for a lot of things, but the community aspect of it. Hello and welcome to the Py Bytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldeboz. 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. Hello and welcome back, everybody, to the Pie Bytes podcast. This is Bob Aldebos, and I'm here with Steve Lott. Steve, welcome to the show. How are you doing? I am doing fabulous. Thanks for having me. Yeah, thanks for hopping on. Excited to talk with you today. You're really well known in the Python space, but assuming our audience might not know you, I always start with an introduction, if you can introduce yourself to the audience, and after that, if you have a win of the week. Yeah, I'm delighted to be here. I have my video background. Here on Zoom is the boat that I live on part of the year and the rest of the year. I live in small apartments and things like that. The boat is a fairly tiny and very noisy space, so the view is lovely, but doing this kind of interview on the boat is really quite a large pain. Connectivity is bad, but for book writing, it means I have to put the boat somewhere near a coffee shop, so I can go to the coffee shop to buy Internet one cup of coffee at a time, which I think is a great thing. I really like that. It's a fine way to write. I think my big win of the week is I just figured this out yesterday. Three days. Three solid days of failing to understand how Matplotlibe works. The secret is, and graphics for me dates back to the seventies, when it was a pen on a plotter and your graphics primitive calls moved the pen and left ink on paper. It doesn't work that way anymore. And I completely failed to understand the Matplotlive artists objects and how a change in state on the artist will cause it to redraw things in its new state. And once I figured that out, oh, boy, what a huge simplification of my stupid program that was. It was delightful. Nice. And how long have you been coding in Python for? Since. Since about the turn of the millennium. So since I started just before this millennium, I like to say that I've been doing it for 1000 years. Rounded up nice. And, yeah, I want to touch upon your book writing as well, because you're, I think, mostly author for pact, and you're working on a new book now. So what book is that? And, well, it's a new addition, so that I have a big Python cookbook with 100 some recipes in it. And so we're doing the third edition of that book. So some of the recipes we're going to Chuck because they didn't age well, and I'm adding some new ones in there. But as the language evolves and as the tooling evolves, the recipes need to evolve to keep up with it. So that's been a lovely thing, doing, like, third editions and stuff for pact. Yeah. I had Antonio Malay on the podcast, and he's very big on updating his Django book, and it's a lot of work. Right. It's hard to keep up. Sometimes it is, and you wind up sometimes in a little rat holes of how much of this should I really cover? So I'm in a place in chapter ten where we're talking about some type conversion things, which means the match statement. And so how much type matching do you want to cover? And the answer is just barely enough to get through the recipe because, boy, it's a deep, deep subject, and the book has a. There's more section after each recipe, and I really have to just stop typing and walk away, maybe get another cup of coffee, come back and delete a bunch, because there's only so much you can cover in a specific recipe. And the match statement is so sophisticated, and all of its little variants and options stop. And is that on you as the author, or does the editor help you with that as well? Yes, they do. And the tech reviewers are often absolutely ruthless in their, don't cover this. This is boring. Or the worst is that's technically not right. So now I got to go re research everything because, oh, wait. You know, and it's not some of the tech reviewers, like Alex Martelli was one of the tech reviewers on a couple of my books. And so at first they didn't know who am was, and then I figured it out finally. And so when Alex Martelli says, you probably ought to rethink this, delete everything, begin again from the very beginning, because that's a profound statement that I missed something fundamental here. The good news is, mostly I was mis describing it. It's not like I completely misunderstood it, but I know other writers reviewing your stuff. Brutal. Wow. So tell me a bit about your process for this. When you start a new book. How do you research what makes the cut? What doesn't? How do you keep motivated? Can be a grind, I guess. Yeah, tell me about it. It's actually joining the various communities, like joining the Pibytes circle. You see the questions people have. There's a group in Pittsburgh called code and supply, and it's a shared workspace in the city of Pittsburgh somewhere that I've never seen, but I know some of the people there. So I joined the shared workspace Slack channel to see what people have to say. And my mastodon account is huge because I follow the python hashtags and you see the questions people have. When I very first started doing this, I had been on stack overflow, and stack overflow just launched. I was an early adopter of stack overflow. At the time, I had a very boring job. I answered way too many stack overflow questions. I wound up in terms of the points you get for your quality of your answers. I was like number seven worldwide briefly, and I've slumped down. I don't think I'm in the top hundred anymore. But I answered a lot of questions, so I saw a lot of confusion and a lot of wrong answers and a lot of things that people just didn't seem to get. And those experiences, the online conversations, are what informed my writing, because some of those questions indicate, like, a profound failure to understand how IEEE float works. And why would you need to understand that? That's the other part of it, because why didn't they know this? And, well, obviously because they have a different agenda. They don't want to understand flow. They have some statistics they're trying to do, because they're trying to make a decision or help somebody make a decision. So they have a business model in their mind that is maybe a little mathematical, and the details of IEEE float is not really front of brain for them. And so now the question is, how do I help them get enough of float to understand why their answers keep coming out just a little wrong way at the end? That's interesting. So I see two things here, right? Like when you want to write or any content production effort. Yeah. Doing a lot of answering questions and research can be really beneficial. And then you build, I call it the bulking phase, right? Build up a lot of materials that way. Plus you get experience teaching and then writing a book. I mean, it's still not easy, but then you have all that materials, and that then makes it easier, right? Yes, yes. And I was a traveling consultant for many, many years before I got a day job that didn't involve so much travel. So I saw lots and lots of customers. And so the experience of having to, you know, my billing rate was huge. So, you know, every minute was something where they were watching you to make sure you were doing something of value. So trying to come to grips with their problem quickly and give them an answer quickly so that they were getting the maximum value for their money, that was a thing that was drilled into me for many, many years. Also what got drilled into me was a hatred of airports because I spent so much time missing flights and waiting for flights and that kind of thing. Yeah, that's why I like the boat travel. It's very slow, 6 miles an hour. Nothing much is happening. And you're in control. Yeah. And you also highlighted then to really understand the fundamental questions, right? Like there might be, people might be asking a symptom thing, but the deeper cause, you learn to really distinguish that, right? Yes, I believe that is really an important thing for their understanding. And it can be challenging sometimes because people sometimes want a quick answer, you know, why when I do it this way, I get one answer and I do it that way, get another answer and, well, you know, now we got to talk about float, and they don't want to hear the whole story about 64 bit and truncation and that kind of thing. And so it's difficult sometimes to address the real question that they have, which is, you know, failure to understand numbers. And so you sometimes have to summarize these things into short, pithy answers. And then when they challenge you, okay, maybe we'll go further, but if they don't challenge you, well, good enough. Cool. And this is also the way how you find projects to pursue to help learn into code. Or is there another tactic involved there? Some of it is helping people learn to code, but most of it at this point, because I'm no longer working for a living, no longer working at an employer. I'm old and retired, so I only write. But I have a great many recreational projects because boat involves navigation. Navigation involves latitudes and longitudes. And if you really want to get serious about that, then you have to understand spherical geometry, and you're not going to do that in your head. That requires a little bit of calculation. So I finally have some Jupiter notebook things with distance and time calculations. And I have a model for diesel fuel consumption and some other things like that that are a kind of interesting little side projects. I've got tons of data, but for the book, let's just take a few rows out of this spreadsheet and convert these latitude, longitude, fuel height things into some other numbers to show multiplies and adds and how a generator expression can be used to compute useful results as an iterator. And then you can sum the iterator to come up with a few rate consumption averages and those sorts of things. And so they're very fun for me because I need it in order to not bang my boat into land very often. But they can be summarized down to a little pithy story that you can tell about starting here, going there, using this much fuel rate times distance. And it's not abstract, it's concrete. It's this boat. Nice. So how you come up with project and is scratching your own itch side benefit is that then also comes back to your writing again. Yes, yes. And you can find examples in there which leads to some, you know, contrived examples. I gotta confess that some of them don't wind up very good. But on the other hand, some of them, because of the concreteness of it, I really like them. Yeah, that's. Sorry. That's why we always try with pie bytes as well. Since the early days of the code challenge is always like, keep it fun, have some sort of themes. We had these favorite movies, we had inception from Nolan, and then, oh, that's kind of cool, right? And then it just resonates more with people. I think it does. I think it does a lot. I was teaching a Java class one time years ago, talking about ordinary sort of class and class hierarchy and inheritance things. And some one, I had an example, and I don't remember what example I had in the class, but during the exercise time, writing your own code, one of the students had a bunch of questions about playing cards. Oh, playing cards, they only have two attributes, a rank and a suit, except they have a number of points. The number of points depends on what game you're playing. Oh, wait a minute. This is a brilliant thank you, student for asking this question about playing cards, because, wow, is that a cool domain of potential problems. Deck of cards, iterator, deal cards, all those things. I love that as a problem. Domain cards are cool. I think they're also right at the start of fluent python, Romalio maybe took notice as well. Any other personal project you want to highlight that you're particularly proud of? The one that I was struggling with with Matplotlibe is a thing for tabletop role playing games. For those of you who play, you know, Pathfinder, dungeons and dragons, or one of those sorts of things, you need to generate a terrain map for this, you know, your fictional world. I like hexagonal maps, and I like the idea of organic growth around something kind of like Conway's game of life, except in hexagons and with some slightly different rules. And so I invented a thing to build cities and countries and stuff for me, and that was fun. But as I mentioned, I had done it completely wrong. Got it to work once, but I wanted the animation to show the organic growth of the border areas. And boy, that animation thing, three days until I realized I was doing it so utterly wrong that it could never work. And then once I got a. To work. Oh, this is fun. And you only find out when you're actually implementing, right? Oh, absolutely, yeah, yeah, yeah. And it doesn't have, doesn't have legs, because it's not a thing almost anybody else ever wants to use. But boy, was it fun for me to get the thing to work. And then this is kind of a cool example of how Matplotlib works. So it may show up in a book somewhere, but the whole backstory on tabletop, role playing games and generating maps. Yeah, I don't know, maybe this is a little too total, too weird. So what do you think of the future of Python? Where is it heading in the coming five to ten years, you think? I think that the thing that is most likely to happen, besides getting the gil out of there so that there's no more global interpreter locked Python 12, 13, 14, kind of evolution to rearrange under the hood there. I think that's potentially a gigantic thing. And each little incremental step along that path to get rid of it, for example, changing the way reference counting works for garbage collection. I read that the pep for that, and it was a presentation that came into icon last year as one of the talks, was how these lifetimes of objects need to change because some of them last forever. The bunch of small integers, true and false, that kind of thing, those objects, the reference counts don't matter because they live forever. And generalizing this just a little bit and how it fixes a bunch of things that are maybe not the best under the hood. All of those small, small changes incrementally, I think, are a wonderful thing. I suspect strongly that somewhere someone is seriously thinking that they might want to rewrite the underlying runtime in rust instead of c. I hope that does in the long run happen that they say, well, what we'll do is we'll have the C python and the rust Python, and eventually they'll stop supporting the C Python, because who wants to support that immensely complicated C compiler stream? Interesting, tiny incremental changes. Those are a wonderful thing. And it means Python will continue on for decades until some other better language arrives. And I can't imagine what that better language might be like. I really am vague on what the gap is that is not filled by python. The complaints that I see are always specious complaints. People don't like indenting with spaces. Give me a break. I've seen your C code. You indent your C code with spaces. And yes, there's curly brackets, but the indentation is clear. You can see the left margin. It's not rocket science. Or the other one is the people who don't like to write too many type hints, so you don't need to, I don't know. Sorry, you don't like them, but they're optional. Yeah. Yeah. Well, that's insightful. And, like, the more. Yeah. The deeper stuff, like refcounts and C python, is that also something you tackle in your books, or is it more. Oh, no, stay away from that kind of thing. Yeah, because there are other people that cover it better. Some of the folks who are like, core contributors and actually have seen the code with their eyeballs, that's their domain. I prefer to write for intermediate programmers, the beginners, and tutorials. That's hard. And I try to stay away from too much tutorial stuff. The intermediate programmer who's been through a tutorial or two and needs more help, that is my sweet spot. My most recent published book from Pact is Python real world projects. And the intent there is to give you things to do like pibytes does. Complete this project, and I give you a bunch of deliverables. You know, here's the concept. And then you got to write acceptance test cases, you got to write unit test cases, you got to write documentation. And, you know, I actually go through and bullet out the files that should be in your project to call it complete, because I used to do that when I was a traveling consultant. We'd have to write project plans and you'd have all the deliverables in the project plan. And I said, wait, I can do this for smaller Python projects. The intent being that if you're an intermediate programmer, you got the language down, but you want to move on to more professional level deliverables. Well, this is what it would look like. This is what I would demand to see before I would pay your bills. Exactly. And then it's so much more than just the python, right? You have the testing refactoring software best practices all the tooling around it. Absolutely. And I'm glad you mentioned the refactoring because I do have a couple of chapters where now go to the previous chapter where we did this, and we're going to take that apart because here's the additional requirement that was hinted at in the previous chapter, but now we're actually going to implement it because some of the short term decisions you make are not good and not very expandable. They don't really follow, like, the solid design principles or some other kind of thing. That is a little deeper concern than just getting code to run. Yeah, very seldomly you get that. All right. It's more. One of our coaches is calling that the different stage of software. Like, first get something working right, then refactor it, or maybe even rewrite it and then refactor it again. So there's like three stages, because first you just need to figure out the requirements. Right. And then you cannot be. Yeah. If you then put up all that premature optimization kind of stuff. Yes. Oh, yes. And a lot of times there's two levels of mystery. There's the requirements that I don't understand and there's the language constructs that I also don't understand. So I have two unrelated degrees of freedom. So there's this giant search space in there. Is this really a requirement of the problem domain? Does this really work in Python? And so the number of combinations of things that I don't know is huge. And the learning process of exploring that very big state space is something that some people don't allow time for. Project planners never allow time for that. You'll have eight weeks to write this. You know, that's two sprints. Like, are you crazy? What makes you think I can do this in two sprints? Why do you even. How did you arrive at that number? Am I a genius? Do I look like a genius? No. I want to pivot a bit to the, or coming back to the python community aspect. So you've mentioned before, like, appreciate the community to see what people are struggling with, what other parts of being part of the Python community has really impacted you professionally, any personal life. It was, it was. The moment was Guido van Rossum's keynote talk where he talked about why I started this python thing. When I was a kid doing electronics and there was a hobby group, and then I was looking at the Internet and programming languages saying, oh, if you had a programming language as your hobby thing on the new Internet thing, then you could collaborate the same way. My electronics group collaborated. That would be fun way to build a community. His goal was not to build a programming language, his goal was to build a community. I about fell out of my chair. I could not believe the whole reversal of the way. Almost everything seems to work in technology. No, I built a better programming language that'll be more optimal, better compiler, better whatever. No, I want to have people get together and cooperate to solve problems. Wow. So when I was working, I worked for quite a while at Capital one, and because of the machine learning data science community had switched over to Python. The data analytics people needed to switch over to Python, and then some of the application developers were switching over to Python. So that uptick in Python around the enterprise was happening while I was there. And people would have me come in for an afternoon to talk a little bit about what's it good for? Why is Python used for the day? Analytics. Why, you know, all the whys and wherefores. And I would always tell them this story about van Rossum building this to build a community. First, it's all about the sharing and the helping and the public access to the code. Everything is about the community. The technology is comes or goes. So we had a giant slack channel there at Capital one. There were like 3000 people in it. And so, you know, when people would ask questions or give snarky answers, we would sort of side coach them because you could, you knew who they were. You know, you could go over to the 14th floor and walk down the hallway and say, maybe don't be so rude to try to make the community thing far more welcoming, because not everybody's all that bright and not everybody's all that experienced. So you have to sometimes slow down your answer or you have to take them offline or you have to have coffee with them. We had a coffee shop downstairs in the lobby. It was part of the building, you know, you still had to pay for your own coffee. It wasn't like free, but oh no, wait, that was in the other building. When I worked out in Richmond, coffee was free. So we'll just go meet at the coffee machine, make little espressos and we'll talk about this. That was a wonderful thing. But the talking about it was the best part about it, that we're here using Python because it is community centric. It's not the best technology, it's the second best technology for a lot of things, but the community aspect of it. I was, and still to this day brings a tear to my eye thinking about the whole idea that let's build a community, not a technology. Yes. People say, right. People come from Python state for the community, but I didn't know that about Guido. That was his initial aim. And by the way, he also invented a pretty awesome language, but for the community, that's amazing. Yeah. And he succeeded greatly then at that, because that's the number one feature. Right? That's absolutely. Yeah, yeah. Everybody stays for the community, because everybody is, or not everybody, but people try to be welcoming and helpful because that's the way it's supposed to go. The boat thing, we moved the boat several times up and down the US east coast, from Annapolis, Maryland, down to Florida and the Bahamas back up. It's a popular thing to do because it's how you avoid hurricane season. You summer up in the Chesapeake and you winter down in the Caribbean and summer in the Chesapeake. So there's tons of people moving boats, and, you know, these are fairly big boats, and by tons of people, it's probably a few thousand, really, not like 100,000 or, you know, even 10,000. So you run into the same people in the same places over and over and over again. We didn't get the community thing about boating until we'd gotten down to Florida and run into the same person four times in four different places. And then, well, we'll have dinner again, because here we are again. Now we're in St. Augustine together. Where are you headed next? And whatnot. And there was, you know, just the number of people all doing similar things is just huge in the boating community as well as in the programming community. And so my partner, for our particular model of boat, my partner has call every other month on Zoom, broadcasts it out through Facebook, mostly to the other owners. And so people dial in from Australia, a couple folks called in from Ecuador, and a bunch of folks, boats were made in Canada, from Canada, and us staying in an apartment, wishing we were on our boat. But no, no, the community building thing, my partner, not a programmer, but sort of got the whole community building thing, so, you know, we can do this for the boat as well as you and your silly programming language. And your silly programming language books. That's cool. So you saw that translated from the python role to the boating space and how, I guess, the synergies and the multiple benefits that the community has. Right? Absolutely. Yeah. And the whole boating thing and you moving around, you introduced me to the term technomad. Yeah. Which I. Well, nomad, I know, right? But I hadn't heard technomad. I've never seen tech jammed on the front of it like that. Exactly. So you're moving around a lot, I guess, you know, the writing part that keeps you pretty. You know, you can be pretty flexible with that. Yes. Yeah. How is that lifestyle? What drives you with that? The point of having a sailboat is to live in a fairly green environment. It's wind driven for the most part, although it does have a big, stinky diesel engine in there, 80 hp, which is, I forget, 80 kw or something like that, more or less. But, you know, sails in the diesel engine. But you're also not living in a big building and you're not driving a big car. On the front of our sailboat, there's a little upside down rubber inflatable boat. We have a propane outboard motor for that, so it burns relatively clean propane instead of gasoline. So that whole living relatively green. But the other part of that is to live relatively small. Also, we had a house with multiple bedrooms, and it was in upstate New York, where you have to have a snowblower and a lawnmower and tons of maintenance and on and on and on. And we realized we didn't really like all the house maintenance stuff. We liked looking at things, and you always had to go somewhere to get out of your house to go look at something. And we said, well, wait, if we were living on a boat, then you would just walk up the companionway ladder and sit in your cockpit, and then you would have the ocean right there. People pay tons of money to rent beachfront houses. No, we are the beachfront. We're in the boat right there in the harbor that everybody's taking pictures of. So we said, let's do that, instead of have big, expensive houses and places. And our kids moved from New York, one lives in Los Angeles and the other lives in Las Vegas. And so we were looking at each other in rural upstairs state, New York, trying to put a new clutch on the snowblower, saying, why are we doing this? Our kids don't live here. So that was when we decided to just sell everything and get a boat and live on it part time and drive back and forth across the country. There's a lot to see. I don't know if you've driven around America very much, but it's vast beyond the comprehension of mortals. And all of it is sort of unique. So why not? No, that's amazing, because, yeah, a lot of people, they just stay with, you know, what they're used to and stuff. So it's kind of a radical change. But it sounds really inspiring as well. Like you're right into nature. Right. And also, it's a smaller space, so you have to make choices. You have to get rid of stuff. So, yeah, that's pretty amazing. What brought you down to Spain? Well, adventure, you know, wanting to change scenery and discover, you know, maybe not being 100% content with Holland as well, with boring and the weather and, you know, and you have to take a risk. Might work, might not work, but then you go back and nothing happens. Right. Like work out. So how's your Spanish? Oh, I fluent. I speak it every day. Oh, good. Yeah. Do they laugh at your accent, or do you. Have you managed to get rid of your accent? I think they chuckle inside, but they never do that in my face. Yeah. We have that problem coming from upstate New York and going down to Maryland. We lived there for many years and then down to Florida and here in Texas that we're obviously not from around there, and there isn't much we can do about that. One of the big things that it took me a long time to figure out is, if you're from New York, you say New York. If you're not from New York, you say New York. And so the New Yorkers saying New York, I was upstate New York is the way we say it, and that's a giveaway that you're from there. So we both worked on practicing to say New York, so at least we didn't sound that much like we were from New York. That's subtle. Yeah, yeah. But the accent's still, you know, a big giveaway that we're from the northeast. Yeah. Never get rid of the accent. Right. I don't not easily know. I mean, there are people who do. A good friend of mine in New York is an actor, and so he does the accent learning things. So he had a role in a play where he was playing a Russian, so he had to go to the russian voice coach and learn the russian accent, you know, the Moscow russian accent, because that's what the voice coaches usually teach you. And so he could drop in and out of that pretty well for when he. While the play was running. And so it is possible, but then you forget sometimes there are some words that you never master. Yeah. Cool. So I got lived in. Sorry. My daughter lived in Sweden for a while, and Swedish is pronounced enough different from English that there are some words that she simply did not even try to say. So she's a waitress, and she can't say the swedish version of milk because that vowel thing, and the word is the same, it's spelled m something lk. And they, like, write an o with an, um, loud over it or something, but it's impossible for an American to pronounce. And so she would offer dairy products to the customers because she did not want to even say the word milk because it was such a giveaway. The rest of it she could pass, kind of because she was way in the northern part of Sweden where most everybody speaks both Finn and Swedish. And so the fact that her accent was not local, everybody just assumed, oh, you must be from southern Sweden, like Stockholm or something. No, that wasn't her accent either. Her accent is american. Some people would figure that out, but there were words she avoided because her accent was just so horrible. But that's another adventure of the adventurous nature, right? Like, you meet a lot of foreign people and cultures, right? Yep. Learn to eat other food. You learned to eat salmon and potatoes up there. Awesome. Hey, I wanted to ask you about mindset finally, as the last question, or. Well, I still have another question, but, yeah. So what are common obstacles you see learners face when diving into python? And what mindset tips would you have for them to overcome those hurdles? One of the biggest obstacles that I see, there's two forms of it, but it's the same obstacle. And the obstacle is making assumptions that are ridiculous, but you don't know they're ridiculous because they're assumptions. So you kind of assume they're naturally right. Sometimes those assumptions are because, you know, another programming language. So you're. You're basically writing C code in Python syntax, and you're assuming a great deal about Python as you write C code. The other assumptions are people that haven't done much programming and that sort of don't get how programming works. So they assume all kinds of wonderful things about computers and programming languages and whatnot, none of which turn out to be true. But unwinding your personal assumptions is really hard. So my big win on figuring Matplotlib out, it was three days to unwind my assumption about how graphics work and how the matplotlib engine works those assumptions. You know, I'm kind of experienced at unwinding my assumptions, but it still took me three solid days to do it because, of course it works like x, when in fact, that's not even a little bit true. It works like Y. And so that it was, I believe that is the biggest obstacle that people face, is they have assumptions and they're not really aware they have assumptions, and they labor under those assumptions. They debug entirely the wrong thing. I don't know how many different times I reinstalled matplotlib in Jupyter lab because I was pretty sure it was just my setup. So I'm going to add a thing and remove a thing and build another virtual environment. Build another, another virtual environment. Every one of those worked beautifully because that wasn't the underlying problem. And after about the fifth install, it began to dawn on me. I began to challenge my assumption that it's probably not my setup on this machine, it's probably something else I'm doing wrong. What could that possibly be? And that requires a little bit of distance sometimes. So the part of the reason it's three days is after the second day and after a couple of Laphroaig single malt scotches, it became clear that I was assuming something. So now let's go back and check off all the things that are not in the documentation that I made up. And you find one of those boxes where you say, well, I didn't see this in the documentation, so why did I write it this way? That's how you find an assumption. That's interesting. Yeah. So it's almost like unlearning stuff versus learning. I mean, we can all learn stuff, but it's actually unlearning certain bad habits, not jumping to conclusions. Challenge your own thinking. There's almost like sometimes we have this bias, right? Like, oh, that's wrong. Right. But maybe you're wrong, or your setup is wrong, and how to distance yourself then, from these false assumptions. My partner worked for General Electric, big manufacturing company in research and development in Schenectady, but it was General Electric, and the manufacturing thing is sort of central to the whole mental lifestyle at GE. So something would break on the boat, or something would be badly on the boat, or something would be near failure on the boat, and I'd fix it, and they would ask, what did you change? And they really need a detailed answer because they still think about, I mean, we own it, we're not making another boat. But they think about maintenance and repair on the boat. More like a manufacturing problem than it just make it stop making noise. No. What is the noise? And what did you change to get rid of the noise? And is that really a permanent fix, or does it have to be ongoing maintenance? And that mental discipline of, what did you change? Why did you change it? What are the consequences of the change? It applies to software also, and it's a little weird because you're typing along in your backspace. Wait, wait, wait. I just made a change. I took a construct out. Why did I take that oh, I know why I took that out. Okay, so now it will go forward from there. But it really helps to think about these things when you're refactoring. What are the consequences of the refactoring? What problem am I anticipating? What am I going to fix when I refactor it and stuff? The boat is a fairly complicated, interrelated bunch of systems, and unlike many things in your life where you say, oh, my pen for my iPad doesn't work right. There's no real consequence to it not working right. You're not. You know, something doesn't work on the boat. Oh, wait. That's life critical. This. We could. We could drown. Let me just. Let me think this all the way through and make sure I really understand it before it gets all the way to the point where we have to. Have to do something about this. Yeah. One of the ones we had recently, before last hurricane season, when we were moving the boat down there. Hurricane Ian from last year did some damage to the boat. But one of the things we discovered when we were living in. In the Florida Keys near marathon, was that the light at the top of the mast was not working. And so you need to have a light when you're anchored. And also, if you're underway at night in the dark, you need to have running lights. And the masthead running light is principal for a sailboat. There are deck level running lights that you can use, but they're not the primary. So that light being out was one of those. Oh, garbage. So somebody's got to go up the mast and figure out what's wrong with it and come down the mast, and we got to get replacement parts, and we go up the mast and replace it. Go down the mast. So you have to think all those things through very carefully. And then what should you buy two $600 lights so that you have another spare? Well, we assumed the light instrument, the actual bulb, was dead, so we bought a spare, knowing that we got one up there that's dead. We've got one in a box. Climb up. It's the wires that have gone bad. That instrument at the top is working, but the connectors had popped apart because, of course, it's on the top of the thing there with sun beating down on it. It was ten years old, so the ten year old insulation had come apart. So I redid the wires, but I have the new light and I have the old light. So the new light is despair, and the wires are all better and things like that. But that was one of those things where we knew we had the problem. It's not life critical, but it's mission critical in that we can't anchor legally. We can be in a mooring field, and we could be in a dock, but we can't anchor out. And mooring fields cost money. Docks cost a lot of money. And since we try to do this cheaply, that means we really need the anchoring light, and it really needs to work. So this is one of those things that's multiple trips up the mast and lots of hand wringing over something that it's not that big a deal. It's just a light. Come on. How hard could it be? But in the long run, it's right. And they had the whole checklist, and I had to explain the wiring thing to them several times to make it clear that this is not a permanent fix. But every five years, we have to go up and look at the wires again. Yeah, but also proper root cause analysis. Right. Not jumping to a conclusion. Exactly. Challenging all the assumptions. Because I had assumed the light was wrong. And it turns out, no, the light was fine. It was the wiring. And it often happens in software as well. Exactly. Yeah. I assumed my installation was wrong. No, no, no. It was my use of the matplotlib artist abstraction. Today, we had some form submissions, and some part of the forum from Jotform was not in there. And Jotform Bug and I reached out to support, and they said, like, well, you can actually configure how your email notifications gets to you. So it was a user error, of course. Nothing wrong. Nothing wrong with jotform. So I assumed it was a jotform bug, but it was actually. I didn't configure it. Well, yeah, yeah. Lastly, what are you reading? I'm too busy writing. Well, no, not really, because we live on the boat some of the year. Not all of the year, but, you know, things are very small and quiet. Most of the time, it's just me and my partner. Partner cooks. I'm not allowed anywhere near fire or knives, so I really can't cook. So partner cooks. I have to do something. So I read, and so I have books that I read aloud. I've been reading aloud to them for, I don't know, decades now, 20 years, maybe, something like that. So, you know, endless. Endless fiction and a little bit of nonfiction. And for some of the fiction, I even act out the voices, although that can go badly. I read the entire Game of Thrones, all the George RR Martin books to them, and starting at the beginning of book one, I had no clue. I'd never seen it before. And I used my most theatrical voice for the guy that gets killed at the end of book one. And so now I got five more books, and I've. He used my most theatrical voice for a guy who's dead at the end of book one. What do you do now? That was. That was sort of awkward. I try to pre read a little bit there, but right now we're reading a series by a writer, Robin Hobbes, and they have really sort of compelling fantasy narratives that are fun to read. And I can do some of the voices and things. And Hobbes lived on a boat for a while also. So a lot of the parts of the story that bump into sailing are well done. Cool. Also interesting that you read out loud. I tried that for a while, and then you have to slow down a little bit. But it does, you know, you retain more what you read, right? I believe you do. And also because, you know, they're right there in the galley cooking. So the whole conversations. Wait, what? Didn't they cover that in the previous chapter, or have they mentioned that yet? I said, no, I think this is foreshadowing. And so we have the little meta discussions and then go back to the story arc. And so that part of it is a lot of fun because you're both reading the same book at the same time, so it's cool for two. Nice. So mostly fiction then, right? Generally, yes. Nonfiction doesn't work out well because, you know, table 3.2, what am I going to do? Read the rows of the table, you know. Yeah. Awesome. On fiction code examples. That might be something. Cool. Well, then you wind up in the argument over, is it pronounced tuple or tuple? Oh, no, I never know. I always make some up. Well, and, you know, the whole dutch thing and the american thing, there may be a bias toward tuple for people to speak Dutch, where there's a kind of a bias toward tuple for some Americans but not others. Yeah. I think my mispronunciation potentially is definitely due to the accent, maybe. And then there's the regional stuff. In the US, you drive back and forth, and when I lived in the east, we drank soda. You know, Coca Cola. The generic category for Coca Cola is soda in the east, but in the midwest and the far west, it's pop, and in the south it's coke. Coke is the generic term for soda in the south, so you can have a coke that is called Pepsi. Interesting. Anyway, cool. Thanks for sharing all this today. Any final words or where can people find you? I mean, you mentioned mastodon. Yes. So I can definitely link that. The Fostodon server, foss free open source software. Fostodon. And so I'm just slot 56, number 56 on the Fostodon server. And that generally is where I spent. But the pie bytes community is delightful. I'm on there also. I'm easier to find there because it's not as big in the Pibytes circle is a lovely place. Nice. Yeah. I'd be really happy with the transition from slack. Slack feels more like a work tool. And so, I mean, it's a great tool. Right. But not for that purpose. Right. And this feels like a community, so it's. And it's growing. So people share really cool stuff. So yeah, people can hit you up there as well. And of course they should check out your book. We'll link that as our books. We will link that as well. And yeah, I'm excited for this one because the cookbook, the short tip format, that's close to our hearts. So I'm really looking forward to reading that new edition. And part of rewriting it is doctest unit test cases for everything. The previous edition had test cases for most things, but the technology of publishing means copy and paste from the code into a docx file to send off to the publisher, which is terrible. Mistakes happen and stuff doesn't get copied and pasted all the time. I fixed it, but I didn't copy and paste it into both examples in the book. It's terrible. Now I'm using latex. We're including the code examples straight out of the source files. So if there's any question or problem, add a unit test case. Yes, it works. Make sure that it's the right line. Numbers are being incorporated in the book, and all the quality for my purposes is considerably better because many, many more test cases for some of the edgy examples. Nice. That's a great tip. Yeah. Especially as your books and content grow. Have a regression at suite. Exactly. Yeah. I think Sebastian Fastapi had something similar for the docs. He maintained we're growing and you just need to have something like that because otherwise bugs will just sneak in. Yeah. And the copying and pasting code is a terrible, terrible thing to do. I hate that. Yeah. Well, thanks, Steve. Thanks for hopping on. It was fun. We can talk for hours, but we have it. Wrap it up somewhere, so. Yeah, yeah. Thanks and have a great day. Yeah. And I'll see you on pibytes. Oh, yeah, sure. We hope you enjoyed this episode. To hear more from us, go to pybites friends, 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.