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 Beldebos. 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. This is Bob Beldebos. I'm here with Chris May on the Pibytes podcast. Chris, how are you doing? I'm well. How are you? Yeah, good. Excellent. We had you recently on episode 119, and now we have you back already because refactoring is kind of important, and it's always nice talking with you. So how are you doing today, Blake? Was, man, I'm doing really well. It's another Monday morning for us, and I can't stay away. Right. I mean, I guess I have to come back often for the hygiene of refactoring and everything. Yeah. On that note, actually, I was listening to Brian's new podcast, people Python, and he had Brett Cannon on. Not sure if you heard that episode, but it's next to my queue. Okay. Yeah, I got good news for you, because he was saying that him and team, and I think, is he still at Microsoft? Whatever. But they spent, like, 25% on refactoring, and it had an enormous gain, so. Oh, man, that's good to hear. So hearing that. Yeah, yeah, 25%. So, like, one week per month they spend on refactoring or improving their tool sets because goes kind of hand in hand. Yeah, that's impressive. Especially that they are given that much time, you know, like, I know that. I think you saw my talk at PI Texas. Yeah. And, you know, I talked about how I think it was. Was it 10% of the time that they were fighting for? Yeah, 10% of the time they fought for, and it made a huge difference. So I'm. I'm just amazed at 25%. Yeah. And the Google work on your own stuff is 20%, and this is 25%. How about that? Yeah. But EO saying it was actually paying dividends, like, it was a huge, huge boost. So. Interesting. So I thought about you when he was mentioning that. So, yeah, well, we're going to talk about today, refactoring, not surprisingly. And specifically, we wanted to talk about the flocking rules, right? That's right. And, yeah, we found that in 99 bottles of oop by Sandy Metz and Katrina and Owen, a book we mentioned last time. And you highly recommend it. I'm now 42% in, so I'm making my way through it. It's definitely interesting. It doesn't matter that it's ruby, JavaScript or whatever languages they have. They don't have Python, but I'm reading it in JavaScript. It's very doable coding wise, because it touches upon these higher level concepts. And around 20 or 30% in, you come around. Yeah, they introduce the flocking rules. Do you want to tell us what it is and why it matters? Absolutely, yeah. One thing I want to. Well, let's describe what the flocking rules are first. There are essentially three simple rules that allow you to refactor your code and, and allow great design to emerge from the code you already have. And so step one is you select the things that are most alike. You know, you look through your code, find what's most alike, and then two, you want to identify the smallest difference between them. And sometimes you might want to rearrange your code or something like that. Like they show a couple examples later in the book, and Sandy has shown in some of her talks that sometimes it's nice to even just change how you're formatting things, whatever. Just make it as obvious as you can what the smallest difference is between your two pieces of code. And then the third step is make the simplest change that will remove that difference. And they suggest doing it in four phases, which they call parse the new code. Parse and execute it. Parse, execute and use its result, and then delete unused code. And the way I think about it, I essentially think about those four steps as like creating a new component and running your tests to make sure you have no syntax bugs, implement your solution on that new thing to make sure. And running tests, make sure there are no issues with how you implemented it, and then essentially hook up or replace one of the differences with a call to new component. And then you run your test, make sure the behavior is the same. So I mentioned it's really hard if you're listening on audio to really get this. The good news is, as we mentioned in the last episode, I have the python refactoring toolkit, and the free version has a flocking rules in it. So I want to, I feel like it's so important that everybody should really know what the flocking rules are. Awesome. Well, we'll link to that. So. And there you, I guess you give a more practical example then, right? I would think so. Honestly, I wanted to try to download the free version just so I could see exactly what's in it today, but I ran out of time before our podcast sure. But that saying, I mean, like, you know, like, I'm available on the pibyte slack. And like, I love talking about refactoring, so. And the flocking rules are something like, once you really get it and see it in examples, it's really powerful. Yeah, it is. And again, going back to doing that, making that extra effort continuously to keep your code base sane so you don't add up technical depth over time. By the way, I think, talking about Slack, didn't we make a dedicated refactoring channel last time? That's right, we did hallucinating right now. So, yeah, just a quick shout out to our community, people. Join and hit us up in the channel to further discuss this. Absolutely. Yeah. So making small, gradual changes and I guess between every phase. Run your test, right? Yeah. To see if you don't mess anything up. And one thing I like about the flocking rules in particular is so Sandy and Katrina are two senior level developers. They're trainers, they work in Ruby, and they wanted to write the 99 bottles of object oriented programming. But to, like, let me take a step back. Sandy has already written a book on, like, I think it was practical object oriented design or something like that. And the two of them wanted to, like, write a book that just even distilled further down how to write good software with classes and, you know, testing and all these things. But they knew that they needed a way to kind of explain refactoring. And obviously, there's the Martin Fowler book, which is impressive. And for me at least, it was hard to get into. And it's dense. Yeah, because it's a catalog of hundreds and hundreds of refactorings. Right, exactly. Yeah. And I think they both had read that book and, like, one of them was very well knew how to refactor and they were working on a piece of code together. And one of them was like, hey, I can't see what we need to do here. I wonder how we can make this better. And the other one was like, you know what? Like, I can totally see it. We need to introduce three classes and, you know, make these things behave in this way and would be great. And the other one was like, how do you see that? And they talked for a while and realized, like, if the one that could see how to refactor couldn't explain why and how there was an opportunity for teaching here. And it took them two years to come up with these flocking rules, which is impressive to me. Not only that they stuck through it and spent these two years, but it's amazing how it literally allows great design to emerge from your code. And I think in particular, it's so important because with Fowler's book, which I don't want to disparage, because it's really good to know all of those refactorings. But what you tend to do is you pick one that's either your favorite or one that you know well. And it's essentially pretty easy to pick one that is forcing you down a line that may not be the best for your code. Whereas the flocking rules actually, like I said, again, allow great design to emerge from your code. Ah, okay. So I see. So I think this is important to highlight more, like, the established refactoring literature has your code towards the design, where if you follow the flocking rules, you're going inside out from the code and the design pattern naturally occurs, which is then more in line with your code without forcefully. I have to do a facade. I have to do ABC. Right, whatever. Exactly. Yeah. Interesting. It's funny, too, because I know this, and I'm working on the project I'm working on now. I introduced all these classes in a hierarchy to try to handle all these things, because I'm even doing test driven development. I know what I want to do here, and I think this is the right way to do it. But I took, like, five steps and kind of realized. I kind of got lost, and I don't know quite what I'm doing. And I realized, okay, I need to just get reset hard and start over from the flocking rules. And the solution, actually much simpler. I didn't need all these classes. And, yeah. Like, I just cannot tell you how impressed I am with the two of them to come up with this gem. Yeah, it's impressive. Yeah. Because if you read Fowler's refactoring, you can get a feeling of, well, everything has been said, you know, it's the Bible, refactoring. Right? That's it. Yeah, absolutely. That's an interesting take. Yeah. And I think it also goes back to, we just don't know the design upfront often. Yeah. So we have that first draft. Like, I think Brian was also discussing that on mentioned podcast. Like. Like, we call it first draft in writing. We don't call it first driving encoding, but it is like that. Right? There are different phases of software. And that's why when people ask me to do a design pattern overview, I'm like, no, I'm not. I mean, we need to know what the common patterns are, but it so much depends on your code. Right. That usually it only makes sense to apply design patterns when you already have your solution and you're refactoring. So. Yeah, so this approach makes a lot of sense. Speaking of which, like, one resource for, you know, like there's the gang of four patterns and all these different patterns. One resource I found was exceptional for Python is Brandon Rhodes. Python patterns. Are you familiar with that? Amazing. Yeah, he's one of my favorite Python speakers. Right. His talks are amazing. Yes. He does a great job because the gang of four book can be quite dense. Although I think, I mean, it's more from the Java background and the old days, maybe, but I think it's still worth reading. But I think you can, if you invest 20, 30% of that time and just go to Brandon's blog and read those entries before, you probably can do it quicker. And it's also pythonic. Right. So you will notice that some of the design patterns see this cards because the standard library or the way we do things in Python has already covered. Right. So you get a nice distillation of what really matters with Python. And, for example, the composition over inheritance. Brilliant. I often link to that. Right. So when people go too deep into oop or inheritance, like, look at that, you know, that's also how you can do it. It's really good. I reread it, take a section and reread it every few months because it's amazing. You can read it and just have such appreciation for it and it just fades away and then coming back, rereading it, just. Oh, I didn't even know that was there. And that's that python patterns guide, in case you're wanting to see this. You're going to definitely link that. Yeah, yeah, yeah. Awesome. Cool. Well, I think that wraps up the flocking rules. Anything else you wanted to say about that? I guess the only other thing that you mentioned earlier, I just wanted to reiterate too, is that the other thing that I think is most powerful about this and also kind of counter to a lot of the ways we work, at least the way I work, is to take small steps. And whether it's, as I'm learning more about test driven development, refactoring, the smaller steps you can take, even commit sometimes into your change control, the better off you're going to be. And for me, it's hard sometimes the kind of shift out of problem solving mode to remember, oh, that's small change. Let's commit. That's a great point. Yeah. And it's also similar to all these best practices in software. Write smaller functions, do smaller commits. The smaller and more isolated your changes, the easier. I remember watching those destroy all software videos from Gary Bernard back in the day. And remember he was doing these small commits and he wanted to make sure that with every commit his test suite would run because then he had that option to revert a commit or it has more points in time, it's more controlled and yeah, that's hard because I think we still, we all are doing too big pull requests too much in one commit. Yeah, yeah. Tell me a bit more about that, about the advantages of that overall. Yeah, it's interesting, like. Cause I feel like I wonder where we get this instilled but it almost feels like we, there's almost like, I don't know if it's a bravado or there seems to be this pressure that I get that like, oh, I need to get work done, and to get work done I just need to plow through. You know, it's almost like you're. I find it when I'm focusing too much on getting a feature out the door, I let everything go to crap, you know, like I don't, I'm not disciplined to follow all the disciplines that I know that I should follow, but in particular, like, if I can, like, I think, like you said it well, like small steps enabled me, number one, to make sure I don't overextend myself because like in programming we're so, it's such a mental challenge and if you move too fast, you're almost putting too much state into your head to try to remember. And so if you work in smaller cycles and then commit them and, you know, run your tests, you're much better. You have guardrails, you've got, you can, you know, have less state in your mind. I imagine you're going to be less tired at the end of the day, which I need to hear this for myself. Yeah, it's surprisingly important, I would say. Cool. And maybe that's also a nice segue into building a second brain. Talking about having too much stuff in your head. So I picked this up when your recommendation. I'm only like 50 pages in. Right. Said before we're reading too many books, but yeah, totally already sold. Note taking, getting back into that, getting more disciplined with it just to get it out of my head. So while you're here, as you have been further in that process, I obviously having read the book and implement it, I just wanted to know. Yeah, what's your second brain look like? It's interesting. So I'm likewise still working on the book. I lost my bookmark, so I forget exactly how far in I am, but I know, whatever. The point is that for the last maybe three years, I've been building my second brain in Obsidian. And it really is. I feel like it's my treasure trove, my refactoring toolkit that I mentioned earlier that it started off as I want to understand refactoring better. And so I started with a few notes in Obsidian and then I kind of deep dove and everything I could find, I put in there. And literally it has. So notes for this podcast are in there. I have it linked to my note on the flocking rules. In addition, I want to say it has my life in there. It's not entirely true because there are people who really go deep in the personal knowledge management world and they have dashboards and trackers of what they're doing. Right now, I'm just focusing on if I find an article that I find interesting, I capture the URL, and if I have time to read it, I will read it and write down why I think it's good. What thing I want to remember from that blog post, put it into obsidian. We pay to have it synced so I can within moments after typing it in my computer, it's on my phone. And yeah, it's really amazing how often something comes up in a meeting or as I'm programming something, I'm like, wait, I remember there was an article on this and I can just quickly search and pull up the note and it's there. Yeah, it's a really cool thing to have. Yeah. Awesome. No, and it doesn't. Also doesn't sound like it's a very complex thing to implement. Right? It's not rocket science, it's just get it out of your head. Decide upon a tool that works for you that's probably like obsidian. I use Dropbox, something that's available both in your desktop as your phone and then just pump information in it and maybe also not worry. Think it about says, like, don't worry about categories. That can all change. So for me, it's, you remember that other book about Zettelkasten, how to take smart note like that Zettelkasten system. For me, that's overkill. Like, with all these indexed cards and sequence numbering, I couldn't get that to work. So what I do these days, I have just a dedicated folder in my Dropbox. I have some shell aliases to quickly add a note. Oh, nice. And it's building up an index by tags, and that's about it. So it's just flat files. And then from the command line, I can just use AG or grep to search through it, and that's probably all I'm going to need. I'm not sure if it scales, but for now, it's only, like, the discipline to actually use it because I set that up a year ago, and now, thanks to the book, I'm actually, it reminded me, like, yeah, you need to put those notes in, right? It's not going to stick here. That's one reason why I love obsidian, too, because it's just flat files as well. It's a markdown. Every note is a markdown file in a folder on your computer. And so it just has a little bit more. It has a UI and some intelligence around it, makes it easier to link to notes and jump between notes. But just like you're saying, like, whether I have obsidian open or not, I can just use the silver searcher to find something I need or. Yeah, it's. It's impressive. Thanks for clarifying that. Yeah, when I said ag, it's. It's actually a silver searcher. Yeah. Recursive grab. The funny thing is, I couldn't think of the name. Yeah. Cool. Awesome. No, that's. That's useful to know. So, yeah, people check out build a second brain by thiago forte, and I think it will boost your. Your productivity. Yeah, it's really inspiring too. Like a later in, like, I'm in a chapter where so the. He has a. His thought is like, you can error out. You can have problems in a couple of ways. Right. You can not collect enough, and you can collect too much. And so one phase of it is essentially like a, like, trying to help you not collect too much by, like, saying, is this really important? But then also, like, kind of essentially going back through certain notes and kind of really distilling in, what. What is this? Why is this important to me and helping you to understand it? Yeah. And so he has a, you know, like, he's able to. He's found really inspiring stories in there. And this one in particular was about this unknown director who, you know, Hollywood. Hollywood. I can't remember the name of the Hollywood group that they wanted to do a story, a particular story on a book, and all the directors turned him down. And they finally went to this one director who was operating in San Francisco instead of Hollywood, and he turned him down initially, but then was reading the book and was like, you know what? No, I think I could really make something special out of this. And he started going through the book taking notes, not only about what jumped, especially what jumped out at him and what emotions. He really kind of wanted to emphasize that the story was telling and literally he wrote in marginalia in the book. And he also created, I think, a bound book for himself where he would collect all his thoughts. And he essentially ended up with this big bound book that he used as his guiding principles to make the movie the Godfather. And. Yeah, and so now, of course, we know Francis Ford Coppola and the amazing thing that the Godfather was, and it's all partially because of his little personal knowledge management of like, really just distilling what it was important for him about the story. That's amazing. Well, that's a nice story to wrap it up. Yeah, that's really cool. Anything else you wanted to share? Just. Just a reminder for my python refactoring toolkit. You can get it at everydaysuperpowers dot de v toolkit. I'm online, I'm not as available. I have Twitter chrismay. I'm not as active on there, but if you reach out to me I would definitely reply. But I'm more on mastodon or fostodon at Chris may as well. And my website, everydaysuperpowers dot de v. I try to put very useful things up there. Of course you can also reach me on the python bytes slack channel. I'm active there and enjoy the community there. So that's about all I can think of. Awesome. So fasted on. I'm at slack and well, first of all, your blog and subscribe. You do send out emails as well. Useful stuff every week or every other week? Yeah, I could sometimes do every week. I try to do every week, but I've been really busy recently so it's not been as. Yeah, but I try to make it very useful no matter what. Yeah, short and useful. I can attest that. Yeah. Cool. Well, thanks for being on today again. Chris was always fun and insightful talking with you, so thanks for sharing your knowledge and experience. I'm sure the audience will get a lot out of it and. Yeah, well, thanks for having me on. We'll surely have you back another day to dive into more coding, design, refactoring, whatnot. Sounds wonderful. Awesome. Have a good day. You too. Thanks. We hope you enjoyed this episode. To hear more from us, go to Pybuyte friends, that is 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 pybytes community. That's Pybit es community. We hope to see you there and catch you in the next episode.