Sometimes we want to optimize or make code beautiful at the start, and that's often not how it works. More often, it's really about hacking. It's getting something to work, but get it to work. Get it actually out there, and then iterate over that. 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'm Bob Balderboss. If you're looking to improve your python, your career, and learn a mindset for success, this is the podcast for you. Let's get started. How's it going, man? You doing well? Yeah. Exciting. It's Monday when we record this, and new week ahead, new opportunities. Right? So it's always refreshing. The last week didn't end. What are you talking about? All right, so we're going to jump in, straight into this episode. This is an episode about getting unstuck, and this is something. Yeah. With code specifically, not in the mud. I think a lot of people tend to hit this problem, Bob, when they're working on projects and initiatives and just anything that's out of the ordinary, where you have to learn. And one of the pain points when they're doing that is that they get stuck. They don't know something, and they don't know how to proceed, and they don't know how to solve the problem, and something just messes with them and it just frustrates them and it's. I think we've all been there. What about you? Yeah, definitely. Like, getting better as a programmer means tackling more complex problems. And you inherently are going to get stuck. It's going to get money, you will have to get your hands dirty, and there's just not another way. And it can be frustrating. Right? Totally. So that is why, dear listener, my friend, we have decided to put together a quick list, just a couple of things each to help you out. So I'm going to kick this off. You ready, Bob? Yeah. All right. So the first thing, and this is an oldie but a goodie. It's walk away from the problem for a while. And it's so stereotypical. I apologize. I know you all hate me for it, but it's so true. It happens all the time. The second you just separate yourself from the thing that's frustrating, you just get away, clear your head, disappear for a while. Well, it'll come to you. And even if it doesn't, when you come back to your code, it'll come to you, and it's going to happen sooner or later. It just giving yourself that little bit of downtime from it is so important. It just gets you out of it. And when you come back, you're fresh. It's beautiful thing. Yeah. You go into some sort of tunnel vision, I guess, right. That very. You're just not seeing the solution. And the best way you can do is then to just literally walk away, get a glass of water or park the problem for half a day. Literally get away from it. Yeah. Get ten glasses of water. One glass is too quick. All right. What's yours, Bob? Well, that's a nice segue into the exercising, right. Coding. Sometimes it has a diminishing return. So after doing it for 3 hours, 4 hours, whatever, you, you get some. A bit in a, you get a bit in a rut, and then it's great to alternate that with exercise. And when you go into the gym, I used to listen to audible, but now I'm just listening to music and I focus on every next set, on every next rep. I'm doing weight training then. But you can also do that with cardio, whatever. And you come back and you're totally refreshed and all of a sudden you're twice as productive. So the exercising is super important. Do something physical. I think. I think the key thing with the exercising is not just feeling good and the health benefit, of course, but when you're exercising, it's hard. No matter what you're doing, no matter what level you're at, it's difficult. And you're forced to really focus on that next rep. You're forced to divert all your mental energy, your physical strength and energy into that next step, that next push up, that next whatever it is. And you don't, you can't focus on your code when you're doing that. It's just, it's impossible. You can't think about it if you're really putting in the effort for the exercise. And I think that's what helps clear your mind. Yeah, totally. Yeah. All right, next. So, next one. Next one on my list, I want. It's. It's going back to this walking away from the problem a little bit. But sometimes you have to struggle and get stuck so that you can have that moment when you walk away. It seems kind of obvious, but what I mean is, if you haven't struggled, if you haven't gotten stuck, your brain is not sitting there churning away at the problem, trying to think up a solution. And even if you do walk away, you know, you still have that in the back of your head. You may not be focusing on it, but your subconscious is. And to then come back to it. You're familiar with it, but you have a fresh perspective. But I think the key thing I want to point out, and this may not be a tip, the thing I do want to point out is that the struggle is necessary. You know, getting stuck. If you didn't get stuck, you wouldn't have. You wouldn't be investing this brain power into it as you walk away and as you're thinking. So that's just my little two cent there. Yeah. There's value in the actual struggle. It's frustrating, but there's more growth happening than you might realize. You realize that actually, when you then get unstuck, like, wow, actually I. I've grown so. Yeah, yeah, totally. And actually shout out to one of our community, Will, for his help on that one. We had a nice conversation about that, and that's what gave me inspiration for that. He had that light bulb moment he shared with us. Exactly. Thank you, Will. Right. Next, then, is being kind to yourself. If you're not getting there, like, don't beat yourself up. It's very easy when it gets tough to also be challenged from a mindset perspective and start saying negative things to yourself. Like, why I'm not getting this? Am I actually a good programmer? Do I deserve this? And all that negative self talk. And you have to be careful because that can actually be counterproductive. So don't be hard on yourself. We've all been through that struggle, and it's normal. Right. You have to accept that and don't take that personally. Yeah, I agree. I mean, it's so easy to get frustrated with yourself. And I think the key that you said there is, it's counterproductive. You know, if you're busy, frustrated, angry, you're emotional, you're just upset about the situation because you've been sitting there staring at code that for 2 hours. It doesn't work. We've all been there. But when you're emotional, it's. It's not helping you with anything. So the tip in that is to just. Again, well, walking away would help, but just take a step back and control your emotion and look at the situation. Analyze it and remind yourself that it's okay. This is part of the process. It's normal. We all go through it. And these are your coding chops coming in. This is what it's all about, so. Yep. And also, it's the glass half empty, half full. Right. Also, look at all the things you did accomplish. And it's probably more than you want a real, or you want to admit at that moment, right? So, yeah, that's a good one as well. And to help with that, here's the next one. So visualize the problem. So get away from the computer screen, you know, get away from the code if you're at work, which at the moment, not many of us are, but if you happen to have a whiteboard, if you have a piece of paper, anything, just scrap coded out on a piece of paper, draw a diagram or something to show the flow of your program, to show the problem that you're working on, visualize it. So one of my favorite things to do before we all got stuck in lockdown was to get into a room with one of my teammates, and we just grab a marker, not a permanent marker, of course, and whiteboard it out. And we just write on the whiteboard, the whole program what we wanted to achieve, where we were going with it. You know, we do a sort of flowchart of what we were, the inputs, the outputs, all that sort of stuff, you know, and it was amazing. It just. It gets everything out of your head onto paper, onto the whiteboard. And it's a wonderful way of clearing your head so that, you know, it's all there. Okay. It's all on paper. It's all in front of you. And you can relax. You can get that off your shoulders, and then you can look at it, and then you go, okay, there's the missing link. That's where I'm missing. That's the problem right there. And it's a really great way of getting around the roadblocks. Yeah. Because sometimes it's not a coding or syntax or micro problem per se. It might be design. I was reading a book on TDD yesterday and was saying, like, if it's hard to test your code, it's a. It's actually often a design problem. So stepping away and looking at the holistic solution is actually very helpful. And, yeah, you might actually need to change your overall approach. Yeah. And the other thing is perfectionism. Like, sometimes we want to optimize or make code beautiful at the start, and that's often not how it works. More often, it's really about hacking. It's getting something to work, but get it to work, get it actually out there, and then iterate over that. So accept that your solution won't be 100% efficient, but get it out there and then make it better. Yeah, that's it. I really love using that one. Myself because it's so easy to sit there and say my project needs to be complete before I push it. But when you send an inefficient one out, it gives you this momentum. It may be inefficient, fine, but you've got this momentum of, I've just pushed something. I've just made a port request. I've got this going now. Now I can keep building on it. It's a great feeling and it really gets you, builds that momentum, as I've said, but gets you unstuck because you can get to the tricky part later. You've got a foundation to build on, which is important. And often you need that feedback from actual users to see if what you're building is actually useful at all. So it's always better to ship and then it's. Right. Yeah, exactly. Actually that's a beautiful segue into your story, Bob. So we thought what we do, because we're getting to the end of the list and there's obviously plenty more of these, but we just tackled our favorite ones. We thought we'd share a story where we each hit, you know, a roadblock, where we each got stuck and what our issue was, you know, potentially where we could have been better. So, Bob, do you want to kick yours off? Yeah, for sure. So when I joined software developer team a few years ago in Oracle, then I was a bit nervous. You know, I was coding for many years, but not really part of a professional development team and I was remote, so I was just banging. The solution was obviously complex cloud solution product and I was banging my head against the wall and I was just keep getting stuck. And they had warned me that that would have been the case because it was all complex. But looking back, I was just getting stuck for hours. And it was so easy to engage the team, ask them for help. There were always signs that they were willing to help me and it would have been totally justifiable. Yet sometimes, I don't know, maybe you're proud or you just think you can figure things out. You have that engineer inside of you. And ultimately I did ask for help, but not soon enough. And I could have saved a lot of time. And I think it also just set yourself apart if you're asked or if you're asking good questions, there's really no shame in that as long as you put the prep work in, of course, but we assume that you do. But, yeah. So my advice and then what I learned from the story is ask for help, reach out sooner. People are more than willing to help, to share their expertise. And, yeah, it's a win win because it's very, as we know, very satisfactory to teach as well and to share what you've learned and help somebody. So ask for help, don't procrastinate. Yeah, that's a beautiful bit of advice because there's such a stigma around asking for help. A lot of people just are afraid of it. They think it makes them look weak, it makes them look silly, like they don't know, and then it makes them look bad. And that's just not true. People who ask help get results, ask for help get results. You know, it's, it's just how we work. We're humans, we, we collaborate and that's the beauty of it. So we should embrace that. Totally. But as you mentioned, Bob, I think a lot of people are afraid to look, look stupid or dumb by asking questions. And there, there are no bad questions. Yeah, well, you know, like you were saying, the catch is, make sure you've done your homework first. You know, put in the effort, obviously, don't just, I've got a problem. I'm going to go straight and ask, but try, know what you've tried and then that's when you ask. So there you go. We can probably link a resource in this episode, how to ask good technical questions. I remember seeing a blog post about that. I think that's pretty useful. Nice. We'll do that. All right, so I'll jump into my story. My story was just recent, so it's not too long ago. Not like yours, ages ago, joking. So I came across someone who was trying to actually compare two lists. Well, not compare two lists. They had two lists that. We're talking python code here. What was essentially two lists of people, and they wanted to shuffle around, matching these people every month. So every month you'd get paired up with a different person. And I asked them, I said, how are you actually doing this? Are you doing it in code? Is it just a spreadsheet? Are you manually doing it? And I'm instantly thinking about lists. Two lists in python. I thought, this is cool. I wonder how they're doing it. Turns out it was entirely manual through excel. And I thought, oh, no, we can do this with code. The funny thing was I immediately in my head thought of iter tools in Python and I thought, this is the solution. I rat holed myself into using iter tools without thinking anything else. And for half an hour to an hour I was sitting there playing with iter tools, tools, combinations. And I just while I, technically it was doing what I wanted and giving me unique matching or every possible combination unique, but it wasn't giving me, you know, I couldn't randomize it properly. I was just not getting the output I wanted and it just wasn't matching up. And I was so frustrated, I was stuck that in the end I took my own advice here and I walked away. I walked away, I got up, I actually exercised. I, you know, made some lunch and then I came back to the. So it was probably an hour later, an hour or so later came back and straight away I just dropped it at tools and I went to just doing, I'm just going to say in air quotes, I'm just going to say simple coding. Okay. So I didn't use any imported libraries except for import random. All I did was just take the two lists and manipulate them and that was it. And it was just incredible. I got the solution. It gives me a random list every time I random comparison every time I run it. But the thing was, if I hadn't walked away, I would have been stuck in this iter tool cycle, pun intended. And it just would have been very frustrating. But you can laugh, Bob, it's okay. But in the end, I ended up just walking away, finding a solution. When I came back, that was completely different to what I started out with. And that's just to me, one of the important lessons of this one. I love that story. Iter tools for the sake of other tools. Right. But it didn't match your design ultimately. Nope. And, you know, the simplest solution is what got me the desired result. So goes back to the Zen of Python. Right? Simple is better than complex. Exactly, exactly. Gotta print that out again. We hope you enjoyed this episode. To hear more from us, go to Pybytes friends, that's 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 pybit es forward slash community. We hope to see you there and catch you in the next episode.