Summary
In this episode, we discuss the importance of finding balance in software development. We talk about the always grinding culture and how it can lead to burnout. We also discuss the benefits of pausing and pivoting in tech and how it can help us achieve our goals.
Detailed Notes
The conversation started with a discussion about the importance of finding balance in software development. Rob Bright and Michael Milosz talked about how the always grinding culture can lead to burnout and how pausing and pivoting can help. They discussed the benefits of taking breaks and how it can help us recharge and refocus. They also talked about the importance of prioritizing tasks and avoiding multitasking. The conversation also touched on the topic of pivoting, which is not failure, but a strategic redirection. The hosts talked about how pivoting can help us adapt to changing circumstances and achieve our goals.
Highlights
- The importance of pausing and pivoting in tech
- The always grinding culture is often unhealthy and can lead to burnout
- Productivity isn't about motion, but about momentum in the right direction
- The key to life is finding balance and taking breaks
- Pivoting is not failure, but a strategic redirection
Key Takeaways
- Finding balance in software development is essential to achieving success and avoiding burnout.
- Pausing and pivoting can help us achieve our goals and avoid burnout.
- The always grinding culture is often unhealthy and can lead to burnout.
- Prioritizing tasks and avoiding multitasking is important for productivity.
- Pivoting is not failure, but a strategic redirection.
Practical Lessons
- Take breaks and prioritize self-care to avoid burnout.
- Prioritize tasks and avoid multitasking to achieve productivity.
- Be willing to pivot and adapt to changing circumstances.
Strong Lines
- Productivity isn't about motion, but about momentum in the right direction.
- The key to life is finding balance and taking breaks.
- Pivoting is not failure, but a strategic redirection.
Blog Post Angles
- The importance of finding balance in software development.
- The benefits of pausing and pivoting in tech.
- The dangers of the always grinding culture and how to avoid it.
Keywords
- Software development
- Balance
- Burnout
- Pivoting
- Productivity
Transcript Text
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 Developing Better Podcast. We're Building Better Developers. We are here to help you with AI this time around, where we were using some episode topics from two seasons back, and we were throwing in AI and we're seeing what it spits out and discussing that and having some really good discussions, like having a guest on every single episode, talking about prior episodes. And this guest is very kind and effusive in its praise, as we will talk about as we get there. But first, I have to talk about myself because that's what good branding and marketing apparently is. My name is Rob Bright. I happen to be one of the founders of development, or also the founder of RV Consulting, where we are a consulting company that helps you wrangle your technology. You got that technology sprawl, that technology drunk drawer that needs to be cleaned up, or you're trying to figure out what does your technology stack look like? You don't even know what a stack is. Maybe you're starting your business or you're making a pivot and you're like, OK, I need to figure out how to use technology, how to leverage that to do this better. That's why we're here. We'll sit down. We'll talk to you, walk through what your business plans are, where you are, where you're at, what kind of industry you're in, all that kind of goodness. And then we will help you craft a, actually we'll craft for you probably, a technology roadmap. And we can even help you implement it as needed, whether it's through simplification, integration, automation, even innovation. You got something that's like this thing is going to win the world, it's better than sliced bread. We can help you build that. Check us out at rb-sns.com. We've got plenty of stuff there and plenty more coming. Good thing, bad thing. Continuing in the, in the, you know, remote digital war, digital nomad, road warrior kind of phase here, stuff like that. Good thing is I'm able to work anywhere. I was able to sit down the other day, just like grabbed a local Panera, sat down, spent several hours, got a lot done because I just had headphones on, was able to focus. Bad thing about some of these places is that the power structures that they have are not quite enough to charge a higher end laptops such as I have. So sometimes you're going to end up there and you're plugged in for hours and yet your battery is still slowly draining to a slow death. So keep an eye on such things and make sure you've got like some rechargeables and stuff like that. And especially if you're going to go out and do something, you're going to be out for the day or something, wherever you can make sure all your devices get all charged up to 100% if possible, so that you're ready for that day away from a good power source. But right now, you don't have to worry about being charged up because he's going to do it for you. Michael, introduce yourself. Hey, everyone, my name is Michael Milosz. I'm one of the co-founders of DeveloperNURB, Building Better Developers. I'm also the owner of Envision QA, where we help startups and growing companies launch better products faster. That means fewer bugs, smoother customer experiences and less wasted time and more money. We take care of the behind the scenes quality of work so teams can focus on building and scaling. Learn more at EnvisionQA.com. EnvisionQA.com. Good thing, bad things. Good thing, I've been cranking on some work lately, just going heads down, getting a lot of stuff done. You know, the get done approach, doing well. Bad thing, I just have not had a lot of time for anything else lately. So I'm just need to looking forward to the holidays coming up and just going to take some time and get a little R&R. Holidays. See, people talk about holidays. I'm going to be a little bit I'm going to sidetrack this a little bit. And it's like, fortunately to me is not like holidays. It's it's a three day weekend. Yes, it is an opportunity to get yourself like a little bit back on track. But it's not like, you know, I'm not going to be able to get that far. Maybe it's because me, I'm going to be just like, I'm still like scrambling to just do catch up, you know, of any sort, much less get some of the things done that want to get done. However, right now, I do want to get back on track this time around. The last episode that we threw into chat GPT is finding balance, the importance of pausing and pivoting in tech. And so we asked chat GPT and it said, absolutely, here's a tailored podcast episode outline for it. Subtitle it gave us is avoid burnout, avoiding burnout and building better developers through strategic stops, which sounds pretty good. It gave me a prompt, a post prompt slash opening. So let's talk through this one real quick. Welcome to the development of our podcast where we don't just build better software, we build better developers. Today's episode explores something that doesn't get enough attention in the fast paced world of tech, when to pause and when to pivot. Tech moves fast, but moving fast in the wrong direction just gets you lost quicker. Whether you're stuck in a job, a project, or even a mindset, sometimes the smartest move isn't to power through, but to pause. Wow. That's actually a really good little intro there. A little bit of that white space thing. Summit one, the myth of constant hustle. Oh, I'm already pumped about this one. He talking points, the always grinding culture is glorified in tech, but it's often unhealthy burnout isn't just emotional. It leads to bugs, bad decisions and missed opportunities. Signs that you might need pause, irritability, tunnel vision, declining quality and code or communication. Productivity isn't about motion. It's about momentum in the right direction. My favorite word momentum in the right direction, even if it's a little bit incremental, small steps. I cannot say enough about that. This is like in itself is exactly like in a nutshell, one of the things that I wish more of us would embrace that I have found in the last few years is that we found actually the key to life. The secret to happy life or whatever is some of this kind of piece in particular. That always grinding, always working late, all that kind of stuff. And this isn't work life balance. That's actually a different thing. We have a limit to what we can do. What we do as developers in particular, even if you're in a design mode or anything like that is taxing. It is an artistic as well as a thought and a scientific pursuit. And most of you know this, if you've ever taken that pause, when you get to the end of a day, especially the end of a long coding session where you're just like, I need to unplug for a minute. I need to take a walk or something like that. And we don't often because there's that thing ahead of us like, Hey, if I sit down and do this for another 30 minutes, I can solve another problem. I can get something else checked off my list. I can add another feature, you know, things like that. We need to keep in mind that when we go into that next phase, that we probably are not going to be, yeah, it may be very fun and maybe very rewarding, but we're probably not going to be as good doing it as we were the first time around. It's just like, if you go play a sport, let's say you're a basketball player. You go play a game and you win and it's great. And now you can go play another game. Well, great, but you're not going to be as fresh as you were for the first one. And so on now, maybe you're young and you can do a bunch of those, but you know, there's going to be limits to that. I think that there is too much. Um, I think there's, and this is where I struggle as a consultant, actually, is I'll get a little bit under the end of the weeds is that we often set things up to bill by the hour, the working hour that we do is how we get paid. We're trading time for money. And that really is not a good model for software development because it's really not about time as much as it should be about features and things like that. Now that does not mean I'm a fan of fixed price bids and things like that. However, if you do it right, there are ways to do it. I've seen sprint based models where people are just paid paid X amount per sprint. And every sprint you go through, here's the cost. And then you move forward. That's actually seems to be a pretty good approach because it's like, yes, it's fixed, but it's in a fixed mode that sort of works for both sides. You're, you know, if you want to go another round and add more features, great. But you also get to like tweak stuff each sprint along the way. That is why we need to, like, we need to focus on what did we accomplish as opposed to, Hey, I had to stay up till two or three in the morning to get that thing done. And honestly, if you find yourself in a point where you feel like you're going to have to stay up till two or three in the morning, don't, you're going to be far better off, get some decent sleep, step away, go do something else. Cause it is amazing how often we've talked about like the pomodoros and stuff like that, that little bit of focus time and then walking away and then coming back is so much more valuable than just like glowing through it. Those are some thoughts I have. How much stuff Michael? Yeah. So those are all great ideas and talking points, especially, you know, if you find yourself working late into the evening, but the problem is, and you've run into this as much as I have, we have deadlines, we have to get code done. You know, there is a finite amount of time in most projects and budgets for getting things done. And you do want to constantly keep moving the ball forward, but the problem is, unless you're doing one project or working for one company, a lot of us have side hustles or businesses that we're trying to run and typically you'll have more than one customer and you're going to have to juggle, unfortunately, between the two and keep things moving. So sometimes you do fall into that pitfall where you are at 60, 70, 80 hours a week, but the problem is you need to take the break, but you're going to get pushback from your team, your boss, your manager, if you do. So you have to find that balance. It's not always going to be easy. And there's going to be times where you either need to go find another job, another line of business or another customer. That's, you know, when we talk about, you know, maybe it's time to fire that customer, free up your time, eliminate the time wasters or quote unquote, the stressors that are costing you money because they're eating up your time. Uh, other things, you know, finding balance and, you know, the declining productivity, that's probably the biggest one. I liked your idea. You know, you get done, it's late. Maybe you can knock out one more thing. I find the flip side of that. Sometimes it's better to knock out a bunch of small things and try to knock out the one big thing, but. It's like eating the frog. Like you talked about from time to time. Sometimes it's better to take that big thing, do it first. Yes, it may be a slog at the beginning, but then maybe that means you can take a smaller, you know, a longer break and take on a few smaller tasks for a while to kind of give you that little pause in mentality between tasks. Thoughts on that. Um, definitely. I do want to step back first to the idea of, you know, if you, you have a lot of projects and you're doing a lot of stuff and it's just sometimes you need to. They're, you're spread too thin to be able to touch all the projects in the way you need to. Now, in that case, you need to either say no to projects. As Michael said, you could also maybe fire a customer to, if they're sucking up too much of your time. Uh, you can also farm it out, go higher, you know, hire other people, things like that scale up yourself. If you're constantly, which, and honestly, this is a part I work with a lot is I get my schedule point where I'm constantly working more than I really want to do. And realize that I could do this for a while. Then it's like, okay, now it's good time to bring somebody else on, whether it's bring somebody else as a contractor, or maybe even as an employee that I can bring them on and say, okay, now we can handle this bigger workload. There are obviously challenges involved in that, but, uh, somewhere along the way it's like, if you, if you were spread too thin, you have to recognize that you're spread too thin and figure out where you need to make some changes. And sometimes it includes, you know, walking away, uh, as far as whether it's a small task or a big task, I think it is very important to find your rhythm and what you are comfortable with. You're probably not comfortable with 16 hours a day. I'm just going to tell you that most people are like, I, I love to do, I do 14 hours of coding a day every day. And I'm awesome about it. You're probably not that's, you know, Bill Gates used to, like when he got married in the first time, I remember them saying, or I guess it's the only time, um, he cut his hours back to like, cut them back to 14 hours a day, seven days a week. That was what the married life changed for him. Uh, and we've seen how many bugs and issues windows has, maybe that's, or maybe there's something there. Don't want to show shade, but you know, that's, and I think all of us have been there where we know that that project, everybody was not sleeping the last week and it got out the door, but you know, there are bugs and there are mistakes. And yeah, we get yelled at form or whatever. But it's one of those things that's like, yeah, you've got it. You've got to figure out where to push that back and where to stay on your ground and where to understand what your limits are moving along, uh, pausing with purpose, the power of stepping back, how pauses can provide clarity revisiting while you're working on a feature at all. Checking if you're still aligned with the problem you're solving, looking at the bigger picture architecture, user needs, team dynamics, pausing equals recharging plus reevaluating micro pauses, Pomodoro breaks, stepping away from a screen, macro pauses, sabbaticals time off or stepping back from a toxic environment. Um, there's a lot here. So first off with your posit, your pause is where it talks about revisiting what you're working on and why are you working on it, particularly if you're beating your head against the wall, if you've got something where you're like, this solution is just not working, I'm struggling with this bug or this thing's not coming out right. I highly recommend when you get into those situations, starting to get that feel of like, I'm just beating my head against the wall before you knock yourself out from beating your head against the wall, step back and think through, like, go back to like the drawing board a little bit and say, okay, well, what am I trying to do? How do I get there? Try to like divorce yourself from your current solution and just sort of like walk through again, give yourself as best you can, a second set of eyes. And this was great to do when you're not looking at it is to just walk away. And essentially like redesign the solution you're trying to figure through again, because there's a lot of times that that will help you find a path that you didn't do earlier, a possibility that you haven't tried, or maybe you look at it and go, why am I, this doesn't make any sense at all. I shouldn't be doing this. This does not, this is not a feature that adds anything. How did I get here? I don't know, but I get to stop things like that. Um, the other thing is the whole macro pauses. I think that we too often do not take a, you know, take a day and actually more than a day, like take a weekend or a long weekend and get away from stuff. I think it is very helpful. I say this as somebody that will like start twitching and stuff like that, as I get away from some of these things, but they are also very helpful. Um, it is good to like, go, you know, go and not open your electronic devices for a couple of days, go put your, you know, set your phone somewhere that you've, you don't even remember where it is. Um, shut down, you know, get away from emails and things like that. Just go for a walk, go for, um, and really think the idea of like sabbaticals and stuff like that, go spend a day at the lake or at a pool or reading a book or doing whatever you do, you know, doing your hobby, working in the yard. Uh, maybe a couple of days of that. It is amazing how much that stuff will re re energize you. It gives you an opportunity to get out of your, your mental rut. Sometimes you'll solve some problems while you're doing it. And if you're like me, you're almost always going to be itching to just like get back to work and it like gives you a little more motivation when you come back sort of a morale booster in itself. Uh, how much self like. Yeah. So I'll touch on two things here. So the first, you know, pausing with purpose, uh, those micro breaks. If you're using code repositories, commit your code, walk away, come back and do a self code review of what you just did versus your problem. Or if you find yourself and you're thinking you're going down the rabbit hole, stop walk away, take a break, come back and just start over with the problem. Ask yourself, what is the Y? What am I trying to do? What am I trying to accomplish? Then go back and look at the code. Sometimes just reviewing the problem, resetting the problem and revisiting that Y will help get you back on track and hopefully reset you enough to say, ah, okay, this is what I need to be doing. The macro, I I'm horrible at this. Uh, you know, just talked recently last episode about my wedding anniversary the day before that. I literally was pacing because I was afraid of being away from my computer. You know, things on fire, things of that nature. That is a bad sign. That is a sign that you need those micro breaks. Take them, but don't take them and just literally sit in front of another screen. Uh, you know, don't go from a computer screen to a TV screen for 12 hours. Take a break from technology. You have to kind of get away from the same, I guess, set of tools, uh, and things that basically got you there in the first place. Get away from the screens, rest your eyes, go for a walk, read a book, go watch a movie. Movies are not blue screen. They are big predictors. You know, you might get some good popcorn out of it. Might have bad popcorn, but the biggest thing I like about going to a movie theater is it's two and a half hour, two to two and a half hours. You have to silence your phone or you're going to get yelled at popcorn thrown at you. So basically because of the social norms, you should be able to go to a movie theater and you should turn off your phone. You should be taking that break for two and a half hours or better yet, go to a high end restaurant and talk on your phone. You're going to get thrown out. That's another way to kind of reconnect with the people around you. Yeah, I think those are all, those are all great suggestions. And I think with that, I'm not going to have nothing to add. So let's move on to the next one. Uh, segment three, they've says would be pivoting knowing when it's time to shift key talking points, pivots aren't failure. There's a question here about strategic redirection, personal pivots, changing roles, specialties, or work styles, project pivots, killing a feature, switching tech stacks, redefining success criteria. Ask is this still serving the goal or just the sunk costs in tech? Your willingness to adapt often matters more than your original plan. That's a really good quote. I think the sunk costs fallacy is one of the biggest challenges that we have in technology. Definitely, uh, it is real. There is definitely a, uh, uh, cost, uh, a loss, maybe moving from one solution to another, from one platform to another. Uh, but there are ways sometimes to regain that. Now, I think for ourselves, I think, um, you know, changing, changing roles, I think we as depending on where we're at, changing technology is huge. It is a very, to me, at least it is much more fulfilling to, uh, it's like a, it's a reset to go, you know, launch into a new technology or even a new line of business or a new application that, you know, that we haven't dealt with before in an area that we haven't maybe worked with. Um, similarly our roles, it's worth it. Anyways, early on, you should be trying to get as many different roles as you can, whether you're, uh, early on, it's going to be hard to get like a lead or a mentor kind of role, but as you get, you know, even a few years in, you can find like senior and lead roles that you can be a part of, even if it's in just your little, uh, you know, little pond of technology that you're working in. Um, definitely look at, you know, some of the things out there. If you've got an opportunity to talk to maybe like a manager or project managers, uh, the architects, uh, things like that, the, your build team, your CI CD people, configuration management, all those people testing, yes, even QA. And the different areas, you know, front end, back end, middle tier, uh, your graphic designers, all that kind of stuff is figure out some of these things, talk to people, get yourself, at least if you're not in that role in that job to help you shift that mindset a little bit, I think is very helpful to, uh, not only solve your problems, but also to like, you know, regenerate and, and get yourself away from that thing that is draining you a little bit too much. Uh, we talk so often about doing regular, you know, probably twice a week, particularly we talk about at the beginning and the end of the year. And then also a lot of times around mid year is the whole like reviewing what you're doing, where are we at? Is my schedule something that I should change? Is my work style? I think this is something that I have benefited from greatly over the years is adjusting style from, and that is everywhere from where you work to how you work, to when you work, uh, to who you work with, to what kind of lighting do you have? What kind of machines do you have? Do you work on a laptop? Do you work on a computer? Do you work on a laptop? Do you work on a desktop? Do you have a big screen, a little screen, multiple screens? All of those things are useful to make you better where you're at. It helps you figure out where are you comfortable, what works best for you. And also honestly helps you when you're thrown into a situation that's maybe not ideal, at least you've been there before and you're prepared for it. So it's things like, Hey, I'm going to be on a train trip for the next three days, but I still have to get work done. Okay. I know that these certain devices and chargers and stuff like that I need because I'm not going to be able to get work done otherwise. There's a lot in this one. So what are some of your thoughts there? Yeah. So one of the, the, the funny thing is when I hear pivot, the first thing that comes to my mind is multitasking. And when we try to do jobs, we are constantly having to pivot, change focus to get things done. And a lot of people are like, Oh good. I'm good at multitasking. That's not the type of pivot we're talking about here. The type of pivot we want to talk about is I'm doing this challenge. I'm stuck on this. I need to get away from this. I need to pivot to something else to clear my head, to take a break. The Pomodoro technique is great for this. Things like this are the types of pivots you want are the pivots to take your mind off what it is that you're stuck on or the problem that you're dealing with. If you're dealing with a bad customer, try to get them off the phone, take a short break, come back and maybe revisit the problem. The next day or say, Hey, let's pick this back up in a little bit. Let's, you know, walk away. Let me look into this some more, try to diffuse the situation, not increase the stress or the temperament of the current problem that you're dealing with. Take a break. Pivot, look for something else to do to kind of reset your mindset and keep things moving. It does all boil down to the old question. We often say, ask yourself, are you being busy or are you being productive? Because you can sit there and you can bang your head against stuff all day long. And a lot of times you're going to end up actually in a far better situation by taking a break, step away from it, come back to it, as opposed to trying to power your way through it. In particular, like now when we have remote work and stuff like that is very easy to go do things very useful, like you can go change the load of laundry, do some dishes, mow your yard, whatever it is. There's other things you can do to detach and get away for a little bit and then come back and be productive. That will wrap this one up. We're running into it from our time. We don't want to go too long. So as always, shoot us an email info at developer.com. Check us out on Facebook at developer. You can hit us up on X at developer. Obviously the developer, well, obviously, I guess if you're listening to this, but if you're watching this, the developer channel out on YouTube, if you're watching this, you could also listen to this on podcasts, wherever you listen to your podcast, we are there. As always, appreciate your time. We are not done. We've got plenty of with AI episodes ahead of us. 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 to develop a new 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.