If you hadn't taken that step back, you would have just kept going down that rabbit hole, and things might be worse than they are, right? You might have made it worse, rather. And on top of that, you could have dug yourself deeper to the point where you couldn't dig yourself out. Hello, and welcome to the Pibytes podcast, where we talk about Python career and mindset. We're your hosts. I'm Julian Sequeira. And I am Bob Baldebos. If you're looking to improve your python, your career, and learn the mindset for success, this is the podcast for you. Let's get started. Welcome back to another Pie Bytes podcast episode. This is Julian. I'm here with Bob. How's it going? Hey, man. All good. We're back. Welcome, everybody. How are you doing? Yeah, good, good, good. I'm still getting over COVID, as I think I mentioned last. I don't even know if we recorded last week, did we? Anyway, so I'm negative is fantastic. I'm feeling good, but I've got this lingering cough, which is very frustrating. So, uh. But, yeah, you know, it's good to be back on my feet. It's good to feel good again and, uh, just be moving on from there and getting stuff done again. Feels. Feels really good. Um, what about you? How's that? So that. That's actually going to be my win. There's. My win is that I'm feeling relatively healthy again. What about you? Any wins? They're good, bro. Happy to hear. Yeah. That's early in the week for wins. I can put him on the spot. It should always be a win. Come on, man. Well, win has got my swag. My piebite swag. You cannot see it because this audio only. I'm wearing a black t shirt with the pie bites logo on it. I got two very cool mugs. One with the pivots logo and the other with the blue pie bytes. Ninja. So really happy about that. Oh, you got the blue one. Nice. I didn't check that. Stopping the fireballs, you know? Yeah, I love that one. That's a good one. That's my favorite. So now I can't have that. Thanks. You've ruined it for me. Choose one of the other ones. So, yeah, everyone listening. That's actually a really good win for both of us. We had pressure from people in our. In the PDM program saying we want the t shirt. Come on. So, yeah, we put. Slapped the t shirt together and put it up on the store, and the first orders of gone through and Bob I think you're the first one to get it because I reached out to everyone who bought it and said, let me know. Let me know what this t shirt's like. So I'm glad you got it first. The process was smooth, man. I got it in less than a week and I got, like, emails about the tracking and so just. Yeah, thanks for putting that together. It's really nice. And everyone, this is completely unplanned and unintentional advertising for this shit. Oh, look how quickly it delivered. Why I ordered it on Monday and got it on Friday. That's totally unintentional. But thanks, Bob. I really appreciate yourself. That's just the truth, man. I'm talking as a customer right now. It was a good experience. Oh, that's good. No, I'm glad, I'm glad. And we are totally now going to put a link to the shirt in the show notes for this. Might as well do it, right? Yeah, yeah, please have a go. We love it. Obviously it's supporting us, us. And we appreciate anyone who does get out there and buy one of these t shirts stickers as well. Oh, yeah. A lot requested, you know. Yeah. Those nice vinyl stickers that won't destroy your laptop when you eventually take them off. So that was. Yeah, they're one of the requirements that I had for doing that. So I'm glad that worked. All right, so let's. Let's kick off the episode. Let's. Let's get into it. So what are we going to talk about today? What are you going to talk about today? When to step back from your code. When to stop coding. Yes. When you're in trouble. That's when. Is that what you mean? Partly, yes. Yes. So I can kick it off if you want. Yeah. You elaborate. I'm going to stand back, cough on mute and have a sip of water. All right. Cool. Coding can be seriously addicting, as we all know. And I think, you know, a lot of that deep work is necessary. You have to do large sprints to get. Get it done. You will get stuck. It's inherently complex and there's just a lot of grinding. Right. Not an iteration, but sometimes you can go on for too long and your vision kind of gets blurred. Especially the design of an app might not be 100% clear when you start. Right. So sometimes you really need to step back and just go to the whiteboard again or think it through again. Given a practical example, if you want, where this happened last week, of course, go for it. As we mentioned before, here we build our own cms and of course it has commands and all that. It also has tasks. For some reason. We coupled the task feature to the command feature in the sense that when there were open tasks, doing a command on the specific card would clear them. So there was already a red flag there, like, hmm, I commanded on this card. Why are all the open tasks cleared? Not so good. Right. Okay, enhancement. Let's make a checkbox under the command field to clear those tasks. Only if you click sort of like a checkbox and clear the task with this command. So you could command normally, or you could command with the checkbox and then would clear the task. Got a new member on the team using the tool. Okay, I use the checkbox, but I actually wanted to clear one task, not both. Yeah. Okay. Two options. Keep coding, keep banging your head, keep going the same route of the couple design of commands and tasks, or just step backward. And I did. So I was going to just jump in because when a feature request like that comes in, solve it, fix it, you know, it has to be fixed like ASAP, which is all self perceived. But actually something came up and I think we had to record a podcast or do something else. And actually by stepping back and being forced to not solve it straight away when I was later in a gym or just somewhere else, I was thinking it through, like. So I just went to the higher level design, like, why the heck are tasken commenced coupled in the first place? Doesn't make sense. Why should a command trigger task to be autocompleted? So I ripped all that out. Just made task like a complete button on task. And it was completely decoupled, way more usable, fixed. Of course, the issue or the feature request. So the morale of the story is I could have just gone with the same design. And actually it was funny seeing the previous changes we had made to it were already red flags. That was probably not an optimized design or just step back, overhaul the solution. We're all happy. Long story. Hope it makes sense. No, it makes sense. The funny thing was that when it was built, we thought to ourselves, we didn't even consider what will happen if you have multiple tasks per person. So if I have to send an email, if I have to send an invoice, if I have to, whatever the task is for the person, there might be multiple tasks. And we just had it coded that if you add a comment and tick the box to say, yep, mark, tasks is complete, it would be fine because we only ever used it with one task per person. But the second we had Georgia come in and use it. The first thing she thought was, well, hang on. When you've got multiple tasks on a person, I only want to clear one of them, not both. I'm like, oh, so you know what I liked about when you stepped back? And by the way, for everyone, for you, our beautiful listeners, Bob was documenting this, this whole thought process in our channel in slack the day that he did this coding. So I saw this evolution of the idea start from, okay, we're going to do this, we're going to do this. And then he goes to the gym and he comes like, oh, why are we. Let's decouple that. Why are we even going? Why do we have that relationship there? I was actually going to have multiple checkboxes for one per task. And I was like, that's. We get kind of in this. It's almost like having a fixed mindset. Like you're just driving the current design. That's it. Tunnel vision. That's the word I'm most looking for. That's the only option. But you gone. No, no. And it was just. It was really cool because this whole notion of stepping back, we added these reminders or these tasks in as a secondary feature. They weren't part of the initial design, they weren't part of our initial scope. And you've essentially had to add in a to do list system into the tool. Right. And. But we didn't look at it and it took you. We didn't look at it from that perspective. And it took you stepping back, doing that diffused brain thing. Diffused mind from a mind for numbers. Yep. And going to the gym, completely switching off, making your focus on the actual exercising and pushing through. And then it just was like, well, hang on, I need to look at this from the perspective of the overall holistic view, which is, this is a to do list app now that I'm building here, and it needs to work as such. And can you imagine any of the two to do list apps that we've used and that I use personally? If they had that sort of functionality, I'd be like, what is this garbage? But I'm glad you bring that out because that sounds so obvious. Right. Like, tasks should be completable, but this is kind of the beauty of software and how we build apps and how we interact quickly and ship, as we always say, like, ship it and go fast, is that this all organically happened. Like, the tasks were an add on feature. It was not our initial design, so. And that's fine because it's always better to have it out there and it was providing us value. You can always refactor, right? Yep, yep. And that's, and that's also why we're big promoters of stepping back in general for anything that you do. Because when you are that laser focused and have that tunnel vision, you close yourself off to other perspectives, other ideas, other opportunities to grow that idea. So for example, if you'd stayed in that zone of coding, that feature the way that you were first attacking it, forgetting the diffused mind perspective that you went down that path you went down, if you hadn't taken that step back, you would have just kept going down that rabbit hole and things might be worse than they are, right? You might have made it worse, rather. And on top of that, you could have dug yourself deeper to the point where you couldn't dig yourself out, you know? And the worst part is that you then close yourself off to the feedback from other people. You start to feel, if someone came in, if I was to come in and say, oh, it's actually pretty rough, man, we probably shouldn't have it like that, you would have thought to yourself, I just invested 3 hours in this. There's that sunk cost fallacy there, right? So you've gone, but hang on, I've just done all this and now I feel attacked and I feel self conscious, I feel embarrassed. There is this whole mindset perspective to it as well. Taking that step back, and as I've been saying lately, creating that space, taking pause, whatever, however you want to word it, you opened yourself up to some redirection, to some better change. And had we actually had our time zones crossing properly, you probably could have even gotten a call with me and said, hey, let's just bash this out quickly, 15 minutes in a virtual whiteboard, you know, and let's plan it out. So there's so much more you can gain from taking that step back. Yeah, that's awesome. So the funny thing though about this as well, is that this is something we go through, obviously, as we've just mentioned. But this is also something that a lot of our PDM clients, the Piwise developer mindset clients go through. It's something we constantly have to encourage people to do, because when you're in a coaching program such as PDM, you have a finite amount of time. You have the twelve weeks, so you really want to make the most of it. And so people have this, this pressure, this feeling of pressure that, hey, I have to sit there and code for three, 4 hours a day, which is not what we're asking. Right. But they do it because they want to make the most of that time and capitalize on the experience. But you actually get more bang for your buck when you create that space, when you take that step back. And it may not be something like the diffuse miners as Bob as you just did, it may be something like, hey, I'm going to go and speak to the coach about it. I'm going to speak to Eric or Christo or Robin or Michael or Bob or me, you know, and I'm going to find out what the best approach is. You know, I'm going to bounce these ideas off them. I'm going to take that step back, get out of my own mind and do that. And it's really interesting that, you know, it happens to everyone no matter what their level of experience is. Everyone's getting stuck at some point and so encouraging them to take that step back to really think about it is something that we do a lot. And I end up having that conversation with a lot of people in PDM as well, which is great. Yeah, there's a lot of over planning, but sometimes also like reimplementing things from scratch while there is a solution for it. And that can save them a lot of time. Especially for example with Django registration login. That's pretty boring code to be implementing relatively. You can use a plugin like all auth beautiful plugin, takes you 20 minutes or maybe an hour. You have a training on that and that might as well save 6 hours of coding, which will be more fun coding because that would then go towards the core features of the app. So that's an example. Just talking with your coach in PDM or just in general your fellow programmer or colleague or even a rubber duck can get you back on track and save you a lot of. Although there are two sides of this, I was going to say save you a lot of time. But sometimes going through the struggle and even if you spend time implementing something else, you always learn, right? So it's not lost time per se, right? Yep. Yeah, that's true. But there's that fine balance, right? I mean, there's a difference between spending say half an hour diving through some documentation, starting to make some progress, making, you know, slowly progressing your app. There's a difference between that and spending an entire week. So an hour a day, 5 hours on the same thing with making zero progress. There's, there's a big difference. So, you know, finding that balance is. Is super important and I think we've talked about that before. But it's worth mentioning again. Yeah. And also the song bias is a dedicated episode. We will. Yep. So on that note, here's a quick segue. Everyone listening, thank you for listening so far. A quick segue. We've had a lot of people ask us about PDM. We always talk about it. We're not shy about it. We feel we're doing a disservice if we don't talk about it. But one thing we did was we had one of our clients, Blaze. He wanted to share a few words on what his experience in PDM was like, and it's really interesting. It's actually a really great little story that he has there. So we're going to just play that for you now. So we'll cut to that and we'll resume when we get back. The thing about PDM is that it's a different type of boot camp. Most boot camps are for teaching you the things that you know, you don't know. PDM, on the other hand, really teaches you about the things that you didn't know, you didn't know. So that's where I found PDM to be really a unique experience. I'd say if you expect to be engaging in python development for the next five years or longer, then PDM is absolutely worth it because you'll have a coherent foundation in the practices that exist, like in the seams of the development cycle. Otherwise there are things that you just won't know how to discover. If you want to think of Python as like a lifelong resource that you have for being able to express your ideas in software, then PDM is absolutely worth it. All right, welcome back. Thank you, Blaze, for that. We really appreciate you doing that for us and we hope you listening got something out of that and really appreciated or engaged with what Blaze was saying because it's indicative of the experience of many, many, many people in PDM. So. Yeah. Hope you enjoyed that. Yep. And to find out more about PDM, you can just click the link in the show notes. All right, so the last thing I wanted to say about this stepping back thing that I was thinking about, it's not so much about the coding perspective, it's not so much about the mindset. I actually just want to touch on the fact that if you have people close to you, so I'm just. I'm not going to assume everyone has a partner and a family and all that. I'm trying to be inclusive here of our listeners, of you listening, but everyone generally has relationships of some sort, even if it's a best friend. One of the toughest things I've seen is people going down the rabbit hole with coding, not taking that step back, not just to solve the problem, but to focus on their relationships, to get that breath of fresh air, to see the sunlight again. It's very easy to go into a coding rabbit hole. When you have a day job and then you code all night, then day job, then code, day code, it's very easy to forget to take care of your other. The other parts of your life. Right? And one of the things both you and I, Bob, have gotten in trouble with over the years is getting into our coding sprints and getting in trouble with the family. So I think the biggest time from pie bytes that I got in trouble or that I not put my relationship at risk. Of course not. Nothing like that. But I remember getting it was causing some friction, and I was like, oh, geez, you're coding again. Come on. Was when we did our 100 days of code challenge. This is years ago. Oh, my God. But coding a script every second day. You did one day. I did one the second day. So technically, we had a day and a half to code it. But a usable script every day and a half was tough because half of it was coming up with the idea, and the other half was coding it and then having it work and getting it on GitHub and then tagging you in so that you could take over and vice versa. So that, I think, for me, was the biggest cause of grief because I just wasn't taking that step back. I was going too far down the coding rabbit hole. Yeah. What about you? We learned a ton there. That temporary sacrifice. But, yeah, no, I think last week because I got obsessed over this copy and paste feature. So you could basically upload documents under your clipboard. Super cool feature in CMS right now. So you can have, can just copy a couple of files from your desktop, and when you're in on a card, you can control v. Boom. It will upload the files to AWS and show them in the browser. It's almost like magic. Now, we'll do an article about that at some point because I saw that in GitHub and all these, it's kind of the modern standard of uploading files. Just copy him from your clipboard. So I'm wondering, how the heck do you even do that? Of course there was some JavaScript involved, but then, of course, you have to make it work with s three bucket and boto three and super cool. But, yeah. Now, of course, addiction could have done that the next morning, but of course, it had to be done late afternoon, evening. Yep. And you remember the messaging of you getting in trouble. That's right. So that's why I thought I'd mention it, because we've both been there and it may not be coding so much for me these days, but it's certainly. What are you doing? I'm writing it. I'm writing some more stuff. I'm writing an email, I'm sending emails, I'm doing. That's a tough balance. Right. But I think the main takeaway from the episode is more so from a design perspective. Exactly. If you go into tunnel vision, sometimes you have to step back and look at the greater design, and you can save a lot of time just by changing your approach. And of course, talking to people, talking through. Yeah. Getting the other perspectives in there, getting out of that tunnel vision is super important, so. All right, well, look, we'll wrap it up. So thank you, as always, for listening. Before we jump, we are going to talk about what we're reading, but what are you doing at the moment? Yeah, so I shared the Py test book on Twitter, finally got it right. And then there were a couple of comments like, yeah, fluent Python is also great. And I knew that, but I was always like, yeah, I've got to wait till the second edition is out. Well, it's out. So I finally got it on my Kindle and I'm reading that that is the only book. It's pretty dense and large, but it's a good refresher, of course. And I just read it 20 minutes a day. And, yeah, it's still one of the best books on Python, so it's a must read. Back in 2016, I got it recommended on my first PI data conference I went to, and I can definitely say what got me to the next level, of course, was the coding and what we always talk about here. Code. Code. Code. But as a reference work, that was the book that. Really nice coming to the next level. Yeah, now that's good. That's. Is that the one on the bookshelf behind you as well? Yeah, that's the first edition, yeah. Oh, that's the first edition. Right. I think I have that one. I can't remember which one I have. Pretty sure it's from Python. It's very. It goes into a lot of depth. Yeah. And like Python distilled, it does a great job and really filtering out what makes idiomatic python, but what's really important in the standard library, you know, nice. Cool. What about you? Nothing. No, no. New reading. I actually. Just as I've gotten the energy back, I've picked up a book that I put on pause. A fiction book, Secret Commonwealth, just to story. I've been reading. I like it by Philip Pullman, and it's quite enjoyable. But what I did do was I thought, well, I want to feed the brain somewhat. So I opened up Masterclass again and was actually really intrigued to see that there was a scientific thinking course on masterclass video series. I think there's eleven videos in it by Bill Nye, the science guy from. From the US from when, um, back in the nineties. And, yeah, it's. It's actually been really good. I loved his, uh, Netflix series and, uh, I think I've listened to a couple of his audiobooks over the years. And so seeing this masterclass with him on it was really cool. So I'm going through that at the moment and quite enjoying it. It's actually really good. So, yeah, masterclass is awesome. I remember we both watched Chris Wallace. Yeah, crispos at the same time. That's good. That's good. All right, that's wrap. That's it. I'm done. Well, thank you so much as always, for listening. If you have any feedback or thoughts, hit us up on social media info at piebytes, on the email, whatever you want to do. We'd love to hear your thoughts, and we'd love to hear any topics you want to talk about. And yeah, we just love to hear from you, so please drop us a message. Yeah, don't hesitate to reach out. We really appreciate any feedback and stay tuned next week for a very special guest. Oh, can't wait. That's going to be a good one. All right, take care, everyone. Thanks again. Thanks. We hope you enjoyed this episode. To hear more from us, go to Pybite 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.com slash community. That's Pibit es community. We hope to see you there and catch you in the next episode.