0:00

I guess I want to encourage people to, like, be greedy, to take that time for themselves and try refactoring, you know, and. And apply it, like I said, like, kind of like Hynek, like, have that. Be a little bit more of the air you breathe. A part of your everyday coding. 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. Welcome back, everybody, to the Piewites podcast. This is Bob eldels, and I'm here with a very special guest. With me today is Chris May. Chris, how are you doing? I'm wonderful, man. How are you?

Yeah, great. It's our Monday, right? It's your 09: 0:54

00 a.m. It's my

03: 0:58

00 p.m. Where we started. Confirmed. Starting the week off. Right. Yeah, we just confirmed. We both did to Jim. So we're ready, right? Yeah. So today we're going to talk about you, your journey, refactoring, your factoring toolkit, and a bunch of other things, but maybe to start it off. Can you introduce us? Sure. Yeah. My name is. Yeah, I'm a python technical coach. I've been working in Python for over 15 years, and, God, I love it. It's amazing what you can do with Python, and I just am just empowered and passionate to help other people enjoy their programming lives. Nice. That's close to py bytes, right? Helping people grow their python. Yeah, yeah. And I think we go back quite a few years, because I think it was 2019 that we actually met at a Pycon and we were doing some sort of demo of the platform. And, you know, with public speaking, when people say, always get your fixed person, your anchor, you know, to not be overwhelmed by the public. For me, you were that person. Right. You were, very interestingly nodding along, and that really helped me to get over the fear of. Well, the fear is not gone, but with that particular presentation, that was pretty helpful. So I just want to give you a shout out. Thank you. Yeah, I really enjoyed what you and Julian had to say, so I was enthralled. I think we did some live demo of the platform or something. Yeah, yeah, yeah. Cool. And that's where we met. We kept in touch, and here we are. Yeah. So, yeah, maybe you can give a bit of what you do day to day. And how you got into python and then from there on we go into the refactoring. Sure, yeah. So as a python technical coach, I join teams on a temporary basis to help them improve the way they write code, how they talk about code, the way that I work, I tear down knowledge silos. So essentially that try to help elevate the entire team, kind of like a rising tide, lifting all boats, and really just kind of help make last of positive change to teams. It's kind of exciting and I love. Yeah, I feel like it's the job I was born for. Nice how I got into python. I actually was a graphic designer and I went to school to be a computer scientist, but I just couldn't understand the way that they talked about programming and I knew enough to make some websites, but essentially I was always playing around with Photoshop. And essentially, long story short, I ended up switching to graphic design and had a wonderful career starting with graphic design, until at one point I started the programming bug, started raising up again, and I automated some stuff with a programming language called AppleScript and took the opportunity to whatever. There was a business process that took several people on my team over two weeks of working overtime to get it finished. And my script saved them all that because now it would do what they did in two weeks, in 4 hours. Nice. Then I got the bug, so I was like, well, wait a minute, I can program, there's this JavaScript thing. And I finally found out that JavaScript was not the same as Java and started coding in the front end of websites and my desire kept growing to have more power, so I wanted to do server side and just general programming, and a friend told me, hey, you should learn python. And I'm so thankful for him. I really should take him out for lunch sometime to thank him for this at the very least. Yeah. Oh my goodness, it's turned my life around and has given me so many opportunities. Interesting. Yeah. Similar to me how you really got that passion from automating and helping people and reducing their workload. That's interesting. And do you find that because you came from a creative background, do you find that that's helping you in problem solving? Absolutely. It's interesting too, because in graphic design it's all about how can you communicate effectively, but in a visual platform. And so it was especially my first few jobs, I really learned like communication is key and switching into a programmer, I really feel as though there was an article I read early on about how I can't remember what it's called. It was on Smashing magazine. And it kind of related programming to writing prose. Wrote it writing poetry, and how you can craft the code in such a way to either make more sense or to do whatever you want to do. And ever since then, I've really thought a lot about how writing programs, how you write code, communicates different things. That's a really nice segue into the meat of the topic, right? Refactoring. Yeah. In the prep, you had a couple of quotes that you said that are driving you right now, so maybe you want to kick it off. What those are absolutely what those are and why. Yeah, yeah. Essentially, as I've been so to create this refactoring toolkit, part of the reason I did it was because I have been absolutely intimidated by the idea of refactoring very long time. In many ways, I kind of felt like it held me back as a programmer and it held back the teams I was on. When we said we would do refactoring, it seemed to be like the idea would be we did it maybe once a year where we would send a senior developer off on their own to clean up part of the code or add a new dependency or maybe a number of things all at once. Then when they were done, they would come back. It was a nightmare trying to marry their code in with ours, and it just took so much time and it was so painful. But I would see these videos online of these people in other languages or other incredible programmers who would say how wonderful refactoring is. And so anyway, all to say is that inspired me to, like, I want to do research, I want to understand refactoring more. And in doing the research, I came across a few quotes that really jumped out at me, is really speaking to me right now and how I write my code. So the first one was Brett slacken. He had a 2016 pycon US talk, and three minutes into his talk, he talked about, he put the slide up on the screen that showed essentially saying that most people write code so that it works, and as soon as it works, they walk away, they move on to the next thing. But he said that the best developers he knows continue to work on that code and refactor it to make that code obvious. And as he says, the best developers he knows spend up to half their time refactoring, which, like, the first couple times I listened to that, I was just like, sure, whatever. But then it sunk in. Like, whoa, wait a minute. Half their time, there's a. Yeah, like, I just blow my mind that you could, you would spend half of your time that that would be. You would find a return on the investments of your time to. Yeah. With that. So the first quote. Yeah, it's. Sorry if I can chime in. Yeah, that's interesting. And it's goes a little bit back to that creativity part. Right. Of the artist and the craftsmanship of having a stature, which is very rough. And then you keep on chiseling, making cuts to make it beautiful because the first iteration is just this blob and you have to keep working at it to really get that beauty in the code because at first you don't get that. You're just figuring it out and inevitably it's not going to be that clean. Exactly. Yeah. And it's really interesting too. Like the way I think about how I've worked and how I've noticed my teammates work. Usually when we come to a piece of code with a problem that we want to solve or a new feature we want to implement, I feel like we tend to look at the code that's already there and write new code that rhymes with the old code that does similar things. We don't often clean things up. We just look to say, we did it this way up here. I'm just going to copy that or do a similar thing. And if you do that enough times, you just start slowing down and makes it harder and harder to implement new features. And, yeah, I can see why. It's taken me a long time, I feel like, to realize by refactoring and making your code more clearer, more obvious, it can actually speed you up significantly. Yeah. One step back to take two steps forward, right? Yeah, yeah, absolutely. And I've never, like, I've never realized. I mean, even, you know, I've spent a couple of years making this refactoring toolkit, but now that that part is done and I'm kind of refining it, I'm all and really trying to apply it to my life and think how it works. I'm really surprised at how much the return you get on the investment of refactoring. Awesome. Refactoring. The refactoring toolkit. Yes. Yes, I am. So do you want to move on to the second quote? Yes. So the second quote comes from Ward Cunningham. He is the person who coined the term technical debt. But one thing I find interesting is his definition is slightly different than how we use it today. His focus was essentially on making code more understandable. And this isn't quite a direct quote from him, but essentially it conveys the idea he's trying to say. He said, when you finish a session, like a coding session or feature, your code should look as if you had known you were going to do this all along, and as if it had been easy to do. And I just thought that was such an interesting way to say this, you know, like, at his time, he was writing in small talk, and so he specifically said it should look easy, as if it was easy to do in small talk. But I'm like, how does that work with Python? And that's part of what's really been driving me, is when I'm finished with my code, when I'm getting ready to check in my code, I write my commit message, and I think, is it clear what my code is saying? And can I refactor it at all to make it easier? Especially if I come back to this in six months, I can understand it, like, immediately, or if anybody else on my team wants to join in. And it's such an interesting mental challenge, mental exercise to go through, and I've found it very rewarding so far. Yeah, excellent. Yeah. And that's also the challenge. Right. When there's a lot of code to be written, a lot of features, and you go very fast to make that extra time to. Yeah. To look at it again and to make it simpler and, yeah, in the long run, enough to be all, we always come back and like, what the hell did I. Right. I mean, I think most of us have had that experience. Right. Like coming back after a long time and like, what does this mean? Right. It's not explicit or intuitive. Absolutely. And it's also a reminder to try to work in smaller increments, you know, to commit more often, which like, kind of phase in and out of. But the more research I do, the more people are like, this helps tremendously. The more you can commit. Yeah. The smaller the chain chats. It's also good for reviewing. Right. Having smaller pull requests. The more isolated the stuff overall in software, the better. Absolutely. All right, that one is done. Right. You want to move on to quote number three. Sounds great. So I had a conversation with Heineck Schlalock, and he told me, I asked him about what he thought about refactoring, and he told me that he doesnt consider refactoring as a separate thing. Its just a result of having tests and thinking about the design of your code the whole time. And this, I think, pairs well. I think all three of them really have a great synergy. Right. Because this really makes me think about how Brett talks about the best programmers he knows spend half their time, up to half their time refactoring. Hynek almost seems like refactoring is the air he breathes as he's coding. Also, I mentioned earlier about what your code is communicating, your APIs, the choices of whether you're using, say, a tuple or a list or a set of all these little tiny decisions that you make on every line of your code, communicate a certain thing. And, man, it really just drives me to want to be better and to write really cool code. Awesome. Yeah. So the takeaway then would be to make it just part of your integral process. Just don't think of it as an afterthought. Right. Like make it part of your daily thing workflow. Absolutely. There's a talk I gave at PI Texas where there's a story that I talk in there, which has really also inspired me, where it's about this. It's taken from this blog post of this developer named Alex Everloaf, and his team was just struggling under technical debt and was taking so long to get things done, and they fought to get 10% of their time to dedicate, to refactoring and improving their code. And that 10% transformed the team. Their bug count drastically dropped. They no longer had hardly any issues in production that would take down the servers. They felt they enjoyed their job so much more that other teams took notice and said, what changed about you? We want to do that. And they were inspired to refactor. And all this was just at 10% of their time, this was going to the project management and saying, we need this, and project management saying they had a long conversation and they finally agreed on 10%. But I think management, code management, or, I'm sorry, not code manager, project management leaders who are not in code, they don't understand how important it is that we have well written code. And so I also don't think they understand the need for us to refactor. I think most of the time us developers don't understand how much we need refactoring. And so I just. I guess I want to encourage people to, like, be greedy, to take that time for themselves and try refactoring, you know, and. And apply it, like I said, like, kind of like Hynek, like, have that be a little bit more of the air you breathe. A part of your everyday coding. Yeah. And that, of course, starts with having as well, robust test suite, right? So, absolutely. In a 10% example, did that team have already a test suite, do you know? I believe so, yes. They had a test suite. It wasn't necessarily, like, the most comprehensive because he did mention that in order to meet deadlines, they would cut corners and prevent and not write certain tests. But I do believe that as part of this 10%, they would go back and put in better tests. Yeah. Because that's a challenge. I think if the code base doesn't have a test suite, then 10% might not be enough. You really have to buckle down and maybe do 20, 30% to even get to a state in which you can refactor. Because if there are no tests, then, yeah, you cannot refactor. You will be guessing. Right. And take a longer time. Yeah, but that's really great because, yeah, you hit two birds with 1 st. Right. Like, the refactoring will make the code more intuitive, cleaner, and that to get to that state, you need to have test, which, you know, we all know that code with a good test coverage is just more reliable, so. Absolutely. Hey, everyone, just a quick break for a message from our sponsors. And who's the sponsor today? Bob byebytes. That's us. Yes, a message from us. We're sponsoring our own podcast, and this is a message from us just to tell you, go and check out the Pibytes developer mindset program. It's pretty good, isn't it, Bob? Yeah. What's cool about it? It will get you the results you are looking for in your python journey. Whatever your goal happens to be, this is the program for you when it comes to Python. We want to talk to you. We want to help you get there, and this program is going to do it. Bob, quickly, what are some of the things that people have achieved through the program? A high performance music API. A transcoding AI. SaaS app. Coinhub, an app to serve as a cryptocurrency portfolio tracker. Spike two PI, a data science package hosted on PYPi payroll app, a SaaS application that simplifies payroll for small businesses. And my favorite, building confidence. Yes. Mindset. I love it. All right, if you haven't yet, click the link in the show notes, check it out, and let's get back to the episode. And to that. I was just thinking that, like, I know a lot of people, like, I've never been on a team. I've never been on a project that had, like, full tests, you know? So I feel as though most people who are listening to this may kind of feel like they're in a less good place because they don't have tests. And I thought that there was a tutorial given at this year's Python web conference that Zil Gildebra put on. And I thought he had an interesting idea. He had a tool that I think it was. Well, I think Llewellyn it, Falco, I think, made the tool, but I think he and a number of members of the community have created it or made it better. But it's called approval tests. And what I love about it is that if you could just create a string or a JSON object, I like the idea of string, because essentially, whatever your program does, you can probably turn it into a string. And if you hand that string to a function called verify, that approval test creates, that's the easiest way you can get a test because it'll look to see what that output is, store it, and if it changes, it'll throw a failing test. And I thought that was a really interesting way to just create a safety net of minimal tests that, you know, test what your code does. A quick way to set up a safety net to make sure your code continues to do what you think it does. Right. So that's maybe to make it easier for people that see writing tests as a big hurdle. Basically. Well, test all it really is, run your code, get some meaningful output back, and then asserts that that output is some expected hard coded output. Right, exactly. The problem, though, is when you need to do setup and there are external services and you have to do mocking, that's where it gets a bit complex. But I think, yeah, there's definitely this. A couple of things that plague us as developers and in the industry is like that perfectionism, like 100% test coverage or nothing, or premature optimization. These are things that we inherently suffer from. But I'm with you. Right. As long as we can validate the code, have the most important things run automatically, and test it, then we're fine. And that might mean that it's not always 100%. You can have a very good test suite that's 80%. Right. It's really like Pareto. Focus on the 80 20, as long as you can verify. That's kind of your point as well with, how do you call them? The verification test. Right? Yeah, the approval test was the package. Yeah, yeah. Great. Yeah. Anything else you want to say about refactoring overall, or maybe your toolkit specifically? I guess so. I can talk a little bit about my toolkit. It's not quite an ebook. The idea I decided to go with is it's an obsidian vault. Obsidian is a piece of software free program that essentially, you take obsidian and you open up a folder of markdown files, and it does this great thing where it essentially makes it like hypertext, where you can put links and links to different notes. And I did that because there's so many times where you don't know exactly what you need to do. But I have all these code snells in there, so you can click through them and see, is this what's going on? If so, it has recommendations for all these refactoring methods that you can do. So all this is to say is it's very searchable, it's very easy to jump from one place to another. And, yeah, I think it's incredible. In fact, as you were saying, thanks to Hynek's talk at Pycon us this year, I realized, okay, I need to change a couple of my refactoring methods. So I'm actively refactoring and hoping to have another release of it in the next few days. And it's. Yeah, it's just kind of going back through it. It's just. Yeah, I just excited to help people learn how to refactor and enjoy it. Yeah, I found that format really interesting. I think I asked you, can I export it as a Kindle mobi file? But it's really cool that you can click through it. And it's so interactive in a sense. Right. Are there also, like, exercises paired with it? Just not yet. That is something I am planning on doing. Yeah. So. So, yeah, keep your eyes out for that. Yeah, yeah. We'll link all this below, of course, if you're watching on YouTube or in the show notes, also, your excellent talk, PI Texas. Really enjoyed that. Thank you. Covered a lot of this, of course. That was really good. Yeah. So I think that's it for the. Sorry, go on. I was just saying. And there's a free sample as well, because, you know, I think, you know, I. I know not everybody's in a position where they can spend 30, $40 on a thing. So I kind of grabbed a good subsample of the articles in there as a free sample, so you can see if it's for you. That's awesome. Cool. We'll make sure we link that below and. Yeah, thanks for sharing that. Yeah. So, as your first time on the Py Bytes podcast, I have to ask, how important is mindset or a developer? I think it's absolutely critical. You know, um, I was just. In fact, I was just talking with my wife the other day, uh, about how. How our mindset really affects everything. Like I, in particular, I was just thinking about, like, how often we say we want to code in an agile, agile method or with agility, so that when things change, because things always change, that we can adjust our code to do that. But I think about my career and seeing some of my colleagues, when some changes come up, it's like, oh, God, why do we have to do that? Why did they make this decision? But somebody once told me, why do we humans really just don't know what we want? We may say we know what we want, but when we see it, we're like, oh, actually, no, that's. I may have said that's what I wanted, but now that I see it, I realize it's something else. And he said, we shouldn't penalize people for having that realization. And it kind of made me, like, just that statement in and of itself helped me to, like, next time I had a change request to say, like, okay, you know what? We're going to make this better. It's going to be a much better product for making this change. And I don't know, just having that mindset just has freed me, I feel, from years of just, I don't know, having that drama of another change. What? Yeah. Yeah. Interesting. It's also recognizing that how we humans are, right, we can be very ambivalent, and inevitably, that's going to ripple through in the software that a feature on day one might not be the feature, day two. And everything is changing. And you have to be very open minded about that, right? Absolutely. Yeah. I mean, yeah, everything changes. And I think that's part of. Not to tie it back to refactoring, but it's so true. That's why we, part of the reason why we need to refactor is to make our code flexible enough, especially when we come to our code and with a new direction, we can refactor to make our code flexible to support the new direction and. Yeah, it's critical. Yeah, no, that's a great conclusion. Like software, it has to be malleable. Right. It's always going to change inevitably. Right. Absolutely. Refactoring will just make it more robust or more malleable that when those inevitable changes are coming, you don't have to rewrite the whole thing. Basically. Yeah, absolutely. Cool. So what are you reading right now? Right now I'm reading building a second brain by Thiago Forte. Essentially, it's, you know, I mentioned obsidian before he. What I'm trying to do with it is create a second brain. And in some ways, I have. It is obsidian is my treasure trove of everything I find, all the mental things I find valuable. So I have. So, like, my refactoring toolkit started as a folder in my obsidian vault, and I've got, know, tons of python snippets and articles and all the. All my thoughts in there. And thiago. Yeah. Created this book to kind of help people, you know, have this second brain, this kind of digital brain that can kind of help you throughout your life achieve more. And I'm really excited to kind of. I've learned a little bit from him about, like, how he's. He views it and I'm like, yes, I want more. So I'm in the midst of reading that. Cool, well, I'm going to pick that up then, because I'm not that good at note taking at most to do list, and I just get up issues. Yeah. But I'm probably missing out because obsidian seems like a power tool, right? So. Absolutely. And one thing I like about Thiago is he helps give you the tools to figure out which note making program is right for you, whether it's notion. Obsidian, there's a ton of them. Evernote, I think he uses Evernote. There's a ton of them out there. So I love that his advice is just general and spans whichever tool you want to use. Yeah, because we are all different in that sense. Because Julian was saying, by the way, Julian senses, regards and could be here this time, that he would love to be on one day. One day. Yeah, we'll get together, the three of us. But you're saying like, oh, you just work with GitHub issues. I wish my brain was as simple as in that sense, because for me, it's like issue open, issue closed. Right. Whereas other people really need to tag them or group them and. Yeah. So it's different for everybody, but I'm hearing a lot of good things about obsidian, so. And again, I really like how you put that together with the toolkit, a very different format. Yeah. So that's great. Thank you. Yeah. So, Chris, amazing. Thanks for sharing all this. I feel we have covered quite a bit in just 25 minutes or so, but is there any final shout out or thing you want to share or where can people find you, how to connect with you? Yeah. Any links we can put? Absolutely. My website is everydaysuperpowers dot de v dot. That's also the name of my company because that's awesome. Yeah, I love it. There have been several times where I felt like I had superpowers when I learned something new in Python. That's what I want to do is give you the superpowers you can use every day. I've got my blog there. The Python refactoring toolkit is at everydaysuperpowers dot de v toolkit. That's a quick way to get there. You can also find me on Twitter chrismay, though these days I'm more on mastodon@fostadawn.org. Chrismay. If you want to connect with me on LinkedIn, I'm the number one Chris may because apparently there are a number of Chris Mays out there, so I had to come up with something unique. But yeah, like, I. And additionally, like, I am very passionate. I love helping people. So if you have a question about refactoring or want help, like exercises for refactor, reach out to me. I even have a discord server that you can get to through my everydaysuperpowers dot de v website. And man, I'd love to help you on your journey to become more refactor. Well, that's awesome and very generous. So thanks for that. You're also in the pie bytes, like, right? I am. I am. Absolutely. Yes. I guess a section of this audience will be in that community as well, so they can also ping you there. Yeah, please do. Yeah. Cool. Well, thanks. Thanks so much. This was great fun. I hope you could share everything you wanted to share about this fascinating topic as well. And absolutely, we can always do a part. Two new things come up. So, yeah, I could maybe get into a little more detail on some of the refactoring methods that mean the most to me. Let's do that. Let's do a follow up at some point and go more into the meat of the actual refactorings. That will be fun. Maybe do like five favorite ones you use over and over again, like maybe extract method or something. We use that a lot. Right. Like to. Anyway, we'll figure that out. Sounds good. And hey, Bob, thank you for all your work, man. It's amazing, like, what you do, you and Julian and your entire team. I really appreciate what you guys do. So thanks for your time and effort. Thanks so much. Yeah, we've been going strong after six years. Yeah. It's so impressive to see what you guys have built. I'm very excited for you. Um, inspired by you and, um. Yeah. And. And I remember when I. There was a. The audience doesn't know this, but there was a book that I started writing, I don't know, years ago, and you very much encouraged me to get that out there and I haven't, but I have put the refactoring toolkit out there. So I appreciate your. Very happy when we saw you launch that because we, we knew that you had something in the making, right? And seeing you launch it, it was this amazing. And, and again, everybody go watch Chris talk, the py Texas one. Just an amazing talk. So I was really. Yeah, I was really impressed how you did that. So cool. Well, Chris, have a great day. Thanks again for joining us and, yeah, we'll be in touch. Sounds great. All right, cheers. Cheers. We hope you enjoyed this episode. To hear more from us, go to Pybite, France. That is piebbe pybit 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.