235. Overcoming "I Don't Have Enough Time"

I know doing it the right way is best, but I don't have the time. Is that a problem? I want to train more, but my boss won't give me the time. What do I do? These are the questions we will answer in today's episode of Dev Questions.

Website: https://www.DevForge.com/ 
Ask Your Question: https://suggestions.iamtimcorey.com/
Sign Up to Get More Great Developer Content in Your Inbox: https://signup.iamtimcorey.com/

Transcript

Copy Transcript Copied

SPEAKER_01 0:00

I bet you don't have enough time at work. You're probably overloaded. You have too many tasks to accomplish in a day, and you're generally overworked. So how do you ever do things right? How do you take time to make things better when you're barely keeping up? And how do you take time to train and improve when your boss just keeps piling on the real work? So that's what we're going to discuss in today's episode of Dev Questions.

SPEAKER_00 0:37

Welcome to the Dev Questions Podcast with Tim Corey.

SPEAKER_01 0:41

Software development is more than just writing code. So let's talk about the rest of it. Specifically, let's talk about the six steps to overcome being overloaded and actually improve your career at the same time. Now, it's rare that you'll work in an organization as a software developer where you're bored. There are always endless tasks to perform. The better you are at your job, the more tasks you're going to get. Sometimes it feels like you're trying to hold back the ocean. But there are ways to get some breathing room while also getting noticed for your performance. So let's go over them. Number one, and this is going to be in order. So number one, you need to plan your time. People often forget that time is like money. If you don't set up a budget, what happens is it just goes away and you're not sure where it went. So you don't want that for work. So you're gonna have to do some things to give yourself a bit of breathing room. And this is the first step in that is to plan your time, create a budget for your time. And that is difficult because when you work in an organization where meetings are just a way of life and people put meetings in a calendar all the time, that can be difficult. But even just something as simple as saying, I'm gonna block off this hour or these couple hours, and I'm gonna work inside there and have specific things that I'm gonna do and say I'm not available can be helpful. But try to plan out your day and say, okay, I have eight hours tomorrow. What's that going to look like? What can I do to order what I do? Otherwise, here's what happens. What happens is you get in the morning, you check your email, you check your Slack or your Microsoft Teams, whatever the whatever system you use at work, and you catch up on messages and you spend about the first half hour to an hour working on those things. And then you start working on a project and someone messages you. And you go, oh, I'll get that. And you go away from the project for a little bit and you come back after, let's say, even 10 minutes. Well, now you gotta pick back up and it takes some time to get back up and going. By that time, hey, you know what? It's time for a coffee. Or, hey, it's time to run to the bathroom, and you got another interruption. And you come back and you have a meeting coming up in half an hour, so it's not really a time to get back into what you're doing. And before you know it's lunchtime, and then after lunch, well, you're a little groggy, a little bit slow, but you're gonna check your email and get some stuff done that is just kind of busy work, and then you try to get back into work, but then again, another meeting is coming up, and before you know it, the end of the day hits. Well, that's not very effective and efficient. So here's a couple things that I do. For example, when I plan out my time, I really try hard to block certain times. So I say, this block of time, I'm going to do this work. And I try to give big chunks of time to the things that take big chunks of time. For instance, if I'm working on a new feature or fixing a few bugs, well then I want a chunk of time that hopefully is at least an hour, if not two or three. So I put that chunk usually in the first spot in the day. Now, because I control my own schedule now, I don't do that. My first slot of the day is usually for meetings if I have them, or for checking email and responding to things and getting things cleaned up and ready for my day, because I'm not as sharp the first thing in the morning. So, whatever that first chunk is, set that chunk up. But then you're gonna have times where you have just kind of downtime. Time when there's not really things that fit well. For example, when you're done 15 minutes before the next meeting. Well, there's not really stuff that fits in there except answering email and getting back with coworkers and messages and all those little things that you have to do, maybe uh expense reports or other things that are just they take time, but you can do them anytime. So instead of using your best time to do those things, use your best time for your biggest blocks of things you need to get done and then fill in the cracks with the things that really do well at filling in cracks, like checking email and responding to coworkers on your message system. So that's how you can plan out your time to make the best use of it. Okay, so plan your time, create a budget for your time, if at all possible for your whole day, if not at least for chunks of the time. Okay, that's number one. Number two is identify performance improvements for yourself. What are some things you can do to get a little bit more performance out of yourself? Not just work harder because that doesn't work, but instead, there are things you can do to set yourself up for success. Uh, one example I've used before is the Pomodoro technique, where you work and it depends on which, you know, which person you're gonna follow, but basically 20, 25, 15 to 25 minutes in a chunk. And you say, I'm gonna work on this task for this chunk of time. And you set a timer. And then you say, okay, now I get a five-minute break. And then you do it again and again. And after the third one, you get a 15-minute break. And you you actually follow that pattern, not just because of the chunks of work you're getting done, but also because of the reset you get. That reset's actually important. Pushing through that reset is not helpful because that reset of your brain actually allows you to work more per in with more performance, to be more efficient at what you're doing because you're getting that reset. That, you know, just get up from your desk and walk to the water cooler or you know, walk down to the you know the front door and walk outside for two minutes. Just something to reset your brain. That's one way of identifying performance improvements. But also, another one that I have found really helpful is planning tomorrow at the end of today. So what I like to do is at 445. If you leave at 5 p.m. at 445, take the time while everything's fresh in your brain about what you have to do and what's outstanding and what's not quite done yet, take that time and map out your priorities for tomorrow. Now, this kind of kind of comes back into step number one, which is having that uh plan for your time, but this is much more specific on a specific day where you're saying for tomorrow, these are the three things I want to get done. And maybe I'm gonna start by you know continuing this bug fix, and here's where I'm at. Just setting up that can really help the next day. Because when you step, when you walk into your office, you sit down, you get a coffee in hand, you've just sat down from you know traveling and wherever you came from to uh you know, from your house to your work, you sit down at your desk and you turn a computer on, you're getting set to go, and you're like, what now? Well, the first thing that's gonna kind of get in your brain is I'll check my email. Okay, again, you're wasting time. You might say, well, okay, I'm gonna do a big chunk of work I'm gonna get done. Okay, what work? So I gotta figure out, okay, let's go to the task system, let's look at you know whatever system you use to track down issues, maybe JIRA or whatever, where you're in there and okay, let's see what's what's important, and and you waste the first half hour figuring out where to start. So instead of doing that, you've planned out the day before. So you go, okay, there's on my desk, I use Notepad for this. I will type out in Notepad what tomorrow should be, and then instead of shutting down my computer, I sleep my computer. Don't sleep a computer every day, do a reboot, not shut down, restart, reboot, but at least you know once a week for that. That's a side note. But you know, I would sleep my computer. So I turn my computer back on, it's up, it has all my stuff ready. My Visual Studio is open, my you know, SQL Server Management Studio is open, maybe even the page for Azure is up, whatever the case may be, whatever I need is up and running. And I also have my my notepad, which is just here's what to do. And I just jump right in and go. Well, I can get 20, 30 minutes ahead just by doing that. And then another way you could potentially improve your performance is to work in chunks. Again, it comes back to number one, planning for chunks, but working in chunks, where you say, okay, right now I'm gonna do this. This is where my inbox will get to have 20, 30, 50, 100 email in it that are new that I have not read because I won't even open it. I'm saying, today's a recording day. That's what I'm gonna do. And I do that in a chunk. You'll notice that when I record dev questions, if you watch the dev questions on YouTube, you'll notice that my shirt might not change from one dev question to the next one. And ooh, oh no, that's because I'm working in chunks. What I'm doing is saying, okay, I'm not gonna record, you know, set up and get all the things ready to record and record one episode because I can record multiple because it's just me. Well, if I record multiple, then I can not have a setup and teardown time added on to every single episode, but just to the one chunk. So I can save a big chunk of time just by doing multiple in a row. So that's important as well. Say up these chunks. And so there's many different ways that you can kind of reorder or optimize or do things to give yourself a little bit of room. It might not save you a day a week. It's not going to save you a day a week. If it does, you're pretty inefficient beforehand. But it might save you 10 minutes a day, 30 minutes a day. It might save you a little bit of time. That's all we're going for. We're not going for massive time savings. We're going for a little bit of wiggle room. Okay. So those first two steps are about getting a bit of room to just kind of flex and have a little bit of room to move and a little bit of room to make decisions in your day. Because now you're doing the same amount of work and have little gaps where you could do a little bit more. Okay. So you got a little bit of flex in there about what to do. Now, if you're not careful, just like trying to hold back the ocean, it's going to fill in those cracks. Don't let it do that. That's where the next steps come into play. You're going to fill in it, fill in those gaps before something else does. Okay? So you got a little bit of wiggle room with steps one and two. Now, step three, here's where you start to make things better. And the first thing I recommend is called the Boy Scout principle. It's leave things better than you found them. So what that means is that let's say you are fixing a bug and you track down this bug and you found, okay, this method right here, this is what's going on and this is how I can fix it. Well, when you're in an absolute hurry, you fix the problem and you submit that and you go, I'm done. Next thing. Well, if you have a little wiggle room, if you've got a little bit of flex in your schedule, you can take five minutes, 10 minutes, and add on to that bug fix. And what do you add on? Well, you add on something to make things better. One way of doing that might be to look at the code and refactor it a little bit. Make the code a little bit easier to read or a little less wordy for what it's supposed to do, or take out logic that's just bad. Be careful with this. Don't make massive changes that are going to impact your system or cause major issues. But a little refactoring can be really helpful because it makes that method a little faster. It also makes debugging that method next time a little faster. And it just makes your overall code base that little bit better. Now, I would encourage you, if you don't have unit tests, that's the thing you can do. Because if you have unit tests, well, a refactor, you can still run a test and say, yes, it didn't change the overall inputs and outputs of the method. It still works the way it was intended to, but it works better. But if you don't have unit tests, then write them. Now you might say, well, Tim, we don't have unit tests in our application. Oh no, let's start with one. Start with one test. Okay? Write one test on one method. Is it gonna be the entire solution that's gonna save your entire company and make your application so much better? No, it's not. It's barely a drop in the bucket. But here's the deal: the bucket's not gonna get filled by pouring tons into it. You just don't have time for that. And your company probably won't invest in spending all that time pouring so much into the bucket. But if you put it in drop by drop by drop, you will see improvements. You will see over time the bucket starts to fill up. You'll have, you know, one test, then three tests, then five tests. You might have maybe even a couple tests a week, is all you can do. But as that starts to grow, well, you know, at some point you're gonna have a bug that gets caught by one of those tests. And all of a sudden you're like, oh, I saved that time debugging that because we caught it with a test. That's a great thing. And then your coworkers might start getting involved too, but you add more and more and more until you have 50, 100, 200, 500 tests, this massive test suite, and it's because you did it a little bit at a time, following the Boy Scout principle of leaving things better than you found them. So that's number three. Once you've got a little bit of free time to start doing. Number four is what I call micro learning. Now, sometimes people want to learn things and they say, I want to learn everything about this massive topic. You know, whatever that massive topic is, that's great and that can be valuable. And there's a time and a place to do that. However, there's also a time and a place to learn something small that's relevant to your current situation and apply it. So learn something small. 10 minutes, learn one thing. I have a whole series on YouTube called 10 minute trainings. Their focus is on just learning something quick. And no, it's not the complete big picture, and it's not the you know, the best practices and pitfalls and you know, real-world implementations and all the rest of stuff that really is relevant for a lot of training. But sometimes you just need a quick thing, and it's a small enough thing where you're like, I can I can figure this out and apply this. So micro learnings where you say, hey, I'm gonna learn something new that's relevant, and then I'm gonna apply that again, Boy Scout principle, as I go. So maybe it is, you know, you've learned a bit more about your logging framework. And you go, oh, I can do these things to help make debugging easier. And so you add new log statements as you go. Again, you're not trying to add log statements to your entire application, just to the things you fix. But as you go, you start adding these logging statements to help you with debugging. And you figure out how to do that. Or maybe you learn how to use benchmarking. Benchmark.net is a great tool. Well, you learn how to do that and you learn how to then create a simple benchmark you can apply to the new code that you write to validate is it better or not. And you start learning how to do these small things that turn into better performance of your application, better performance for you as a developer, uh, better overall code and cleaner code. And before you know it, these little things have added up. Now, number five is automate something. Now, sometimes people hear automation and think, okay, that's an entire CI CD process, and I want to have GitHub actions and all this stuff. That can be the case, and I highly recommend that you do automate your CI CD process, but that's not what I'm talking about necessarily. It might be something tiny. It might be something like, hey, once a month we import a spreadsheet and it's a CSV file. We have to bring it into Excel and then do some cleanup, and then we import that in the database. We have to do some more cleanup, and then we put that into the right tables. Well, could you write a small application that did part of that process automated? And maybe could you add to it and add to it until it's a complete application that that makes that process a one-step process? So here's one of the things that I do. Again, let's talk about you know how I do recording. Because I'm a software developer. And when I look at what I do, one of the things I look at is how can I automate these things? So when I am done this recording, which I record on video, in case you're listening to a podcast, there's a video version on YouTube. Um, in case you're listening on or watching on YouTube, I have a podcast version of this. It's the same audio. But what we do is we record the raw video and audio. I do it myself in my studio. I'm my studio right now. When I am done, I have a button I push. It stops the recording, and I have another button I push that moves the video file to the right location. It applies the right name to it based upon what I'm teaching on, and it strips out the audio into a separate file so I can run it through a system that does a process, a series of processes on the audio that again are something that's automated. So I drag it into the audio program. I can't automate the actual process of putting it in because the system I use doesn't do that. But it applies a whole bunch of things like noise reduction and audio cleanup and all the rest to the audio. And when it's done, it puts it in a folder called cleaned audio right next to my raw audio and video. And I move that into the raw folder and it overwrites. So now it's the right WAV file, it's the clean WAV file, and then I put it into my OneDrive, which automates it up to the cloud, and then it gives it to my designers who take it from there and turn it into a podcast episode in a video. But most of those processes I have worked on creating little applications to take little chunks out of my time. Because it used to be they would take me, oh, 10 to 15 minutes of this then this then this and and to do these processes. Now it's a button, a drag and drop, and then a drag and drop. And that's it. So I can do this in batch. I've again blocked my time, but then I've also created little automations to make it even better. So you can do the same kind of thing where you automate little pieces to just make your life a little better. Maybe it's something like when you are done with a ticket, you have to email a person and say, this ticket is complete, can you check it? Well, you could automate that process a little bit where you, you know, type into a text, you know, hit a button, type into a text box this ticket number, and it creates the email and auto-sends it to the right person. That would save you a few minutes. That's not a big deal, but it kind of is, because a few minutes every day or a few minutes every bug fix can add up over time. So what you've done is you first set up some wiggle room in your schedule. And then you've used that extra wiggle room to start doing some things that have some compounding effects. Okay? So you've made your code a little better over time. And that's through the Boy Scout principle and also micro learning, which also means you become better and more informed over time. And you've automated things to take away the repetitive things that you do that, you know, when you're super busy, you're like, I don't have time to automate, I'll just do it. But at some point, if you have a little bit of time, automate that and you have even more time. So now you have a little bit more time, which is going to get filled in. Your boss is not going to want you sitting around or automating things. When your boss finds out you have extra time, they're going to fill it. But by doing these things, Things, you'll be able to continually give yourself some more wiggle rum and improve your applications at work. So now step six steps in. Step six is now you have a conversation with your boss. So your performance will have improved. You'll be doing more things, and you'll have be writing better code in the same amount of time. And that automation is going to have a compounding effect, which means you'll be doing even more things and writing even better code. So that's an important thing to talk to your boss about. So the first step is going to be to discuss your performance. So bring this up. You need to talk to your boss and be proactive about your performance review and say, hey, here are the things I've been doing. Because that's going to lead to a better staying in the department, potentially a raise, potentially a bonus at the end of the year, whatever the case may be. Or it's just the fact that you're not the one getting laid off. Whatever the case may be, you are showing that you're a proactive go-getter of an employee while at the same time kind of reducing your stress a bit by giving yourself a little wiggle room. And then another part of that discussion is going to be getting help doing what you're doing. So what I mean by that is you've kind of proven this system works. You've proven that it gives yourself a bit more time and you can create better results by doing these things. So get help. Enlist your boss to have others follow your lead. Do these same things. So, and then ask for time to train to be even better. You're doing microlearning, but there's also a time for taking a step back and having a bigger picture and having bigger chunks that you can do. So you've proven that your system works. You've asked for others to follow in your footsteps and do the same thing, which also kind of puts you as a leader in the department. That might be a good thing. You've also then asked for, hey, can I take the next step in my training to be even better? Okay. So, yes, you know, work is gonna be crazy, and sometimes you just have to keep your head above water or just your nose above water because things are crazy. But there is still an opportunity in that craziness to be better, to get some wiggle room, to improve the systems you're working on, and to get that space you need. It's going to take time, it's not gonna happen overnight, it's not, there's not a quick solution to the problem. And this is a pretty common thing wherever you work. So it's not like just moving to a different organization is going to necessarily solve the problem. In fact, it probably won't. So instead, what you need to think through is how do I follow these steps to be a better employee, to have more margin in my work life, and at the same time get ahead while doing these things. Okay, I hope that's helpful. Thanks for listening. And as always, I am Tim Corey.

SPEAKER_00 25:17

Thank you for joining us for this episode of Dev Questions. When you're ready to learn to think and code like a professional developer, head over to IamtimCorey.com and enroll in a course.