Finding Balance - The Importance of Pausing and Pivoting in Tech

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well hello and welcome back. We are continuing our season. We're talking about the developer journey. In this episode, right to the topic, we're going to talk about effectively when to take a step back, when to pause, when to maybe even pivot a little bit and things along those lines because sometimes we get a little too caught up. We get, it's part of the natures, we get deep in the weeds, we get really focused on whatever that project is, that job is that we're working on, those kinds of things. And the next thing you know, you're like, wow, you're just spinning your wheels. This isn't like death march stuff. It's more like you're in a situation where you just need to effectively take a break. But before we get into that, I need to introduce myself. My name is Rob Brunhead. I am one of the founders of Developing to Build Better Developers. Also a founder of RB Consulting, where we really focus on leveraging technology. So find ways to take your technology sprawl and integrate, automate, simplify and turn it into a lean, mean technology machine instead of the big, honking, ugly, hulky thing that you've had in the past, which also will be a topic I think at some point is like some of these, which we've talked about a few times, some of these situations where people have just stuck around with the technology way too long. Windows XP, I'm looking at you as one of those things. I'm also looking at Michael, who's on the other side. I'm going to let him introduce himself. Well, hello, everyone. My name is Michael Mulash. I am another founder of Developing to Build Better Developers and I'm also the founder of Envision QA. So if you're a small and mid-sized business or a clinical nurse, doctor, whatever, looking to build custom software or you're like Rob said, you have software that's like this monolithic or old archaic that you don't know if it's working for you anymore, give us a call. So taking a step back, this is we've touched on this in some in past seasons and things like that. And it's really it's about it is about productivity versus the activity. There's a difference between being busy and being productive. And in particular, I think we as developers get into this situation particularly early on, but even as we get late into our career sometimes where we are really focused, where I call it sometimes it's the 90% high or the 99% high. I'm almost done. I've almost got this figured out. And so you feel the end like the line is just about there. You're almost to the finish line. And because it's technology or it's programming or whatever it is, the line moves. So you're like I am one configuration file correction from making this all works. And then you do. And then you realize that, oh, that was actually a layer of an onion. You unpeeled it and now you're back in. But you're almost done again. And while that can carry us for a while, that the endorphin hit of basically like I'm almost there. I'm almost there. I'm almost there. There's a point where it's just like you're like a crack addict or something is you've just had too much of that and it doesn't work. And it's really the challenge is figuring out when have you hit a point where you're not being productive anymore and you're really starting to spin your wheels. Now, it doesn't mean that you aren't moving the ball forward a little bit. But what happens is when you're fresh, you can hit it and you can be moving the ball forward quite a bit. But then as you get further into these kinds of cycles, you're not as effective. You're not as productive. And so now you're slowing down your ability to move the ball forward. And it could eventually get to a point where you burn out or something like that and you hit that wall. But even without hitting the wall and burning out, there is definitely periods of time where you just need to walk away, to take a break, whether it is during a day and it's just during your workday and you've got some problem that's really bugging you. Or it could be over a longer period of time where maybe you haven't had a vacation in forever. Maybe you can't even remember the last time you took a break. You took a day off or anything like that. And you do need to. We are not built. We're not machines. We're not built to run 24-7. And no matter how important your project is or your task is, there are going to be times where it's been too important for too long. It's like firefighting. Sometimes you get in a situation at your job. It's like there's a bug. There's an error. There's an error. It's critical. It's critical. It's critical. And then you've just been running around chasing fires, putting them out, saving lives basically for who knows how long. And you get to a point where you just can't do it anymore. You've got to, no matter, sometimes it's no matter how critical stuff is, you will be better off. Everybody will be better off if you step back and take a break. And I think that is one of the hardest things for us to learn is where that line is between determined and driven and driving yourself insane. There you go. That's a good little toss it over to you, Mike. Oh, sanity. Oh, very much so. Like you were saying, this is within our developer journey. And to me, when I hear walking away or burnout, things like that, I picture a person taking a bottle of water, walking out into the desert. And as they start running out of water, they start slowing down, they start crawling. And then eventually you hit that oasis and it's like, oh, I can relax. And then you have to walk all the way back in your slug. And then you finally make it. But that's just an analogy for what really happens in this journey. If you haven't hit it yet, you're going to experience this at some point. I mean, unless you're just one of these people that is always happy, go lucky, and somehow just doesn't, can really not have anything really sticking. You just really don't stress it too much. Interestingly enough, through this process, I actually have put up some kind of guardrails and kind of, I guess, temperature tests to kind of keep me on track personally as I'm going through this process. And one of the big things is, okay, how long have I been working on a particular issue or sprint repeatedly? How many times am I working on the same issue again and again? You mentioned that. But the funny thing is, if you're in this firefighting mode so long and you're making all these little changes, the problem is you eventually lose sight of what the big picture was. You're now way down that rabbit hole and you might have completely rewritten what was supposed to be there into something else. Now you got to take a step back and it's like, well, now what does it do? How do we fix this? How do we... And you're in a whole different bucket of water, hot water. The other thing is, personally, if I... I like playing video games. I like going to the gym. I like reading books, listening to audiobooks, working in the yard occasionally. If I start finding out that I'm not doing that as much and I'm stuck right here in this chair more times than I like, that's another red flag. So when I start seeing those things, it's like, okay, I need to start getting up. I need to go back to the gym for a little bit. I mean, there are times in your life where you need to walk away and there are times where, yes, the appliance is on fire. You have to sit there until it's out or at least fixed enough that the world isn't falling apart. So personally, it's a balancing act. And more times out or not, you miss... You see the signs, but you miss that critical tipping point where it's like, I really should have walked away a week ago or yesterday or an hour ago. Just start looking at your conversations, the people you're talking to. Are you starting to see more problems in what they're doing? Are you seeing more problems in what you're doing? Is the code, is the environment? Are you like, oh, I made this change. Now it's not working. And you just kind of get in these cycles of blame. You're either blaming yourself, you're blaming the code. That's another kind of really red flag. At that point, you need to take a day off or you need to stop and walk away for a little bit. These are just some of the things I run into. What are some of the signs you typically see, Rob, as you go through this as well? Well, it's interesting that there's two things there that I wanted to touch on. As you mentioned, guardrails. And then the other thing is sometimes it's on fire and you have to deal with it. And I'll go with that one first. You have to be cognizant of how often that thing is on fire. A good example was we were having issues with a customer. Years ago, we had issues with this customer where they would send us stuff and there was never really prioritization or anything. And so we really didn't know. You just got to do everything and it's got to be done tomorrow kind of thing. And we said, hey, we've got to back off. We have to pace ourselves. You can't work 24-7 and just every time there's something, it's critical and you've got to go fix it. It's not life or death. And so we said, hey, we're going to have a list of issues. They're all there. And then we need you to help us out and help us prioritize what needs to be done. What's immediately, what's critical and what isn't? And she proceeds to say every single thing is critical. And we're like, okay. We had to push back. We said, okay, let's walk through this. This thing, how critical is that? And it was like, this thing is a different color blue than I want. So I'm going to say, okay, it's not that critical. Okay, well, we're going to pull it off the critical list because we don't need that. We don't need, you cannot run around and saying the world is on fire and the sky is falling with every little thing. And I know it may feel that way and it may, but that's where we have to push back sometimes because they're going to be, and we talked about this actually just before this, we got into this is there is a perception that our customers or our boss or people like that will have because they touch a certain, you know, they work with an application or software we've built. They don't understand because they just see if it works or it doesn't just black or white. They don't see the difference between, oh, that's a typo that we can fix in two seconds versus that's a critical system. Like that's an architectural flaw that's got to be rewritten. It's going to take months. And they don't know necessarily sometimes how important it is. And sometimes we don't, which is where we have to have that conversation is how critical really is this thing? It's things like if you're stopping a critical release, if you come into a go or no go, and you're stopping it because the text on this alert message is a little off, you may want to rethink that. You may want to like, is it really that critical? Particularly if you could roll that out and then you could just pick it right back up in the next release cycle or something like that that doesn't even require a full release. So don't be afraid to push back in those kinds of situations. As Michael said, I think one of them is when you find yourself doing the same thing over and over and over again, a lot of times just because you've gone down a rabbit hole and at some point you have to look at it and say, wait a minute, I need to reset because I'm chasing this thing and I'm not, I'm chasing symptoms. I'm not actually going after the core problem. And that's very critical and I'll toss it back to you. But first I want to talk a little bit about the guardrails. It helps a lot to use your calendar to your advantage. Schedule like regular workouts, schedule time, downtime, and it could be at the beginning or the end of your day. It can also be stuff like have a day that either depending on what your schedule is and things you do, either have like your weekends are always booked as far as anybody's concern so that you can go do stuff. Or maybe it's just your Saturdays or your Sundays or your Thursday nights or whatever. A guy I worked with years ago that was a total workaholic still had 5 p.m. Sunday until he went to bed was family time. That was the key is he was like, I'm going to, that is time that I'm not going to give up to anybody else. And he stuck with it. And it's hard not to respect that when you're, say it's a five day work week. If you're already demanding stuff of them on Saturday and Sunday morning, you can take a couple hours off. And so don't be afraid to push back on that a little bit and the reality that we can't work 24-7, that we do need downtime, that we do need time to be able to even to like what we're working on and to think through the problems and it can't just be firefighting all the time. Thoughts on those? Yeah, I like the counter idea. But unfortunately in this day and age, calendars can be overused or ignored. It's just another, you know, another tool in our arsenal that it could potentially be another notification overload. If you're already burned out, that's just one more thing to add to it. So if you do go that route, I recommend definitely look at using additional tools with that, that we've talked about before, like maybe putting your phone on focus or turning other things off so that while you're in that period, you're not getting, you're not still getting bombarded by other avenues, by other external avenues. The other thing that was kind of interesting there is you talked about, you know, going down the rabbit hole, is seeing the big picture. Sometimes and it's interesting because you and I have both worked together on multiple projects and for some of our bosses in the past, we have had cases where it's not even just that the manager knows about coding. They actually know the code. They may have been people that have written the code in the past. So in their mind, they see what this, how the code is or conceptually was, not necessarily where it is today. And as they start giving out requirements, you start getting things that might mismatch. So as you get into the code and you start making these changes, you get into that cycle of it's broken, it's broken, it's broken. Or they don't give you all the requirements. I love this one. We touched on this briefly before we jumped into the podcast side where, you know, you get into writing the code, you're getting ready to deliver it. You've gone through the so-called test period, UAT, with the users and you find out there's more requirements that weren't talked about. So now here you are rushing to get maybe some critical pieces in before you can even go live. And that is, you know, that can occur with this. But these are things that you just have to kind of be careful of and be mindful of. Because the big thing is, as you go through this journey, it is a journey, you will have ups and downs. It's a matter of kind of figuring out that tipping point when you're starting to slide too far down to pull yourself back up. And that could be pivoting to reading books, playing video games, writing something else, maybe teaching. Just do something else. Maybe go for a walk. But just find the time to recognize, I need to take a pause. You know, we talked about the Promoto. I can never say that right. Pomodoro, folks. Pomodoro. This is a learning joke we have. But use tools like that to help you reset, especially when you start feeling that you're in those cycles. Yeah, and I think a good example that we've got, we do have people that can point to us. And we've got our bosses, our coworkers and things like that, that can help us out a little bit and help us know when we've crossed lines and stuff. A good example of things that we need to be cognizant of, I guess, as we sort of wrap this one up, is when people are trying to reach out and help us out. A perfect example was last night I had spent, I'd been heads down all day. And it was sort of funny because my wife was like, hey, we're going to have a date night. We're just going to go have some drinks and play pool. And I was like, that sounds great. Two hours later, I was still heads down. And I was like, because I was going to make dinner. And I was like, okay, now we're going to have dinner because I didn't even get dinner made. But it was, is one of those when I like, I got up off out of my desk. And I was like, we need to go. And she could tell. I'd say, I need to go now. I need to get away from my desk. I need to get away from the work. I need to go away. And it didn't really impact, like the stuff I wanted to do. Yes, I was a little bit in the zone. But I went away, had a couple of drinks, played pool, took a big long nap, woke up in the night, basically ready to work again and then dove into it for a while. It's like, and I'm old. I'm not a young person. I'm not like 20 years old when you do this all the time. Some of you can. And when I was that young, I could. So don't be afraid to just say, sometimes pull yourself out, particularly when you're working long hours and you've got stuff that are natural rhythms, whether it's taking a lunch break or it's time for dinner or time to go to bed or have a weekend or something like that, is finding ways to take advantage of those because, yes, we overdo those all the time and we want to show off how awesome we are that we didn't sleep for three weeks and we got that project done, but it is not the way to go. The way to go, however, is to give us feedback on this, is to provide us comments, to send us emails. Let us know what you think. Let us know the topics that you like. If you have any requests, we are open to those. You can shoot us an email at info at developernord.com. You can go out to developernord.com. That is D-E-V-E-L-P-R-E-N-E-U-R.com. You can also find us on the YouTube. You can find school.developernord.com. You can find some more content and stuff to go through there. However you subscribe to podcasts, please subscribe and give us some feedback. Let us know where you want to go and where you find value and where we can give you more because we are here not only for us, but also for you. That being said, we are still going to be here. We're not done. This is not our last episode, not even the one of the season. So we're going to come back and continue talking about the developer journey. As always though, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nord Podcast. You can subscribe on Apple Podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember, just a little bit of effort every day ends up adding into great momentum and great success.