Hey everyone and welcome to Developer Tea, my name is Jonathan Cutrell and today I'm going to be talking about why delaying tasks isn't enough and how to deal with overload. For anyone who is listening to this podcast and really everyone on the planet, there's only so much you can do in a given day. This is true for a lot of reasons but the most obvious one is because we all have the same amount of time in a given day. No matter how efficient you become, there's still that upper bound of time and physical limitation that will be present and this maximum output that you have, it doesn't really change much over time. Of course there's some exceptions to that rule. For example, if you are a beginner, especially if you're a beginner developer, you will become much more efficient than you were on day one by day 20 of your experience in development and this output doesn't change much though between a year five and year six. The quality of code you write might change somewhat but at a given point in time that efficiency curve will begin to flatten out and that's because there is a actual limit to how efficient you can become. Now the issue is that as developers, we are commonly asked to do more than we can do in a given time and as developers, we commonly commit to doing more than we can do in a certain amount of time. Humans are notoriously bad at estimating and so we end up over estimating what we can do or we overestimate what should be able to be done in a given amount of time. Now we commonly try to deal with this imbalance of input by delaying our output. For example, we have 50 things that we want to do today and we find out that we can only do 10 of them, we push off the rest the other 40 things to do later. But if we have 50 new things to do tomorrow and we only can do 10 or maybe 11 even, well then the other 39 or 40 get pushed off further and now we have 80 things that are pushed off into this concept of the future that doesn't really even exist because we have a faster inflow than we have output. So the problem with delaying then is that the delay is superficial, we have this concept of the future as being open and free as if we won't have new things coming onto our plates to do tomorrow. We also may have the illusion that we will have more time in the future because we will become more efficient in the future or we will fix the problems that we've currently been experiencing with our efficiency in the future and we will be exponentially more available to do more work. Now I've experienced this time and time again and I'm sure you have as well, it seems virtually impossible to actually become efficient enough to play catch up, to go back and finish all the things that I delayed before as well as keeping up with the unrealistic inflow that has already been established and is continuing and playing catch up and getting better and faster what you're doing, it seems impossible. In the book The Obstacle is the Way, the author Ryan Holiday talks about simple solutions that are not easy and I'm going to give you one of these simple solutions, it's not going to be very easy for you to implement but it will be simple. I'm going to talk about that as soon as I take a quick sponsor break. Thanks so much to today's sponsor, Coachhip. Coachhip is a hosted continuous delivery service focusing on speed, security and customizability. You can set up continuous integration in a matter of seconds and automatically deploy when your tests have passed. Coachhip supports your GitHub and Bitbucket projects and you can get started with their free plan today at Coachhip.com. Should you decide to go with a premium plan, you can save 20% off of any plan for the next three months by using the code Developer Tea. Now that code will be in the show notes so go to Coachhip.com and use the code Developer Tea for 20% off today for fast, secure and customizable continuous integration go to Coachhip.com. I've been talking on this episode about being overloaded with input and being overloaded with demand more than you can keep up with even though you think you can become more efficient over time, how that's really kind of a facade. It's very difficult to actually become efficient enough to keep up and play catch up. And I told you just before the sponsor break that I was going to give you a difficult, yet simple solution to the problem of overload. It's simple in the sense that it's not a 10 step plan that you have to memorize. It's not complicated. It's not there's not a full book that you have to read to understand how to do it. But it's difficult in that it's going to be hard for you to do. It's going to be emotionally difficult and it's probably going to take quite a bit of effort on your part to get used to this solution. And the solution is very simply to say no to more things. Say no to more things. If you're on a team that is working on a product for example, you might have somebody who is taking care of the feature requests, you might need to say no to more feature requests. And that may seem like an uphill battle. It may seem impossible, especially if you're working on behalf of a client. If you're telling that client that they need to pass on a feature that they are suggesting, that can be difficult to convince the client that that is the case. But the reality is, it is much more valuable for you as a developer to be realistic with what you can do in the time you are given and doing the most valuable things with that time that you are given. If you simply put things off until later, then that backlog of items or whatever you want to call it, the list of to-dos grows faster than the application you have built grows. And this leads to major amounts of overhead to try to actually sort through what is the most important thing. So saying no early actually has a lot of added benefits down the line as well. This strategy is also incredibly important for beginners who are just now learning to code. It may seem like you need to learn everything all at once, that you need to learn 10 languages all at once for example. But the reality is you're not going to be able to learn that many languages all at once. In fact, one of the more prolific programmers that I personally follow named Ovedi Grimm, he recently posted a list of languages that he wants to learn. And he also posted languages that he was not going to learn even though he was interested in it. And the reason he posted that was to say, hey, I have to say no to some things in order to make space for the things that I want to say yes to. So the simple yet incredibly difficult to implement solution to time demands that exceed your maximum output is to say no more often. Balance the things that you truly want to say yes to. Create a simple priority list of things that you should and want to say yes to and say no to more of the things at the end of that list. As remember, all of us only have 24 hours in a given day. We all have an upper bound, a limit to what we can do. And if we're always playing ketchup, if we're always doing the things that we put off yesterday, then we can never say yes to the things that we want to say yes to today. So say no more often. Thank you so much for listening to this episode of Developer Tea. I hope it was thought provoking. I hope that it was challenging and I hope that you will be able to say no to more things and have a little bit more sanity and be able to get the things done that you truly need and want to get done. If you have thoughts or questions for me, you can reach out to me on Twitter at at Developer Tea or you can email me at Developer Tea at gmail.com. If this show is providing value to you, the best way you can help me out is to go and leave a review in iTunes that is also the best way to help others out because it helps the show gain a little bit more visibility and it helps other developers just like you find the show more easily. Thank you so much for listening to Developer Tea and until next time, enjoy your tea.