If you're listening to this episode in the morning, then you probably have a pretty good reservoir of willpower remaining for the day. And as it turns out, you can even preserve that willpower. Most recently, studies have come out about ego depletion that challenged some of the previous ideas that we've even talked about on this show. In today's episode, I'm going to talk to you about a way to preserve some of that willpower. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal in the show is to help driven developers like you connect to their career purpose so they can do better work and have a positive influence on people around them. And if you've listened to the show for a long time, you may have heard us talk about ego depletion. And this idea is that as you go throughout your day, as you make decisions, those decisions, you only have a certain number of decisions that you can make in a given day. And then eventually, you lose the willpower to make those decisions as good as you were making them earlier. Of course, we talked on the show last week with Daniel Pink about how our minds kind of have a shape throughout the day. We have this kind of regression in the middle of the day that we're not suited for analytical tasks during that time. And in the evenings for most people, we're better suited to more creative tasks, whereas in the morning, we're better suited to those more analytical tasks that require a lot more focus, a lot more willpower. Of course, these things can probably overlap. These concepts can overlap. But previously, we've discussed on the show kind of this downward slope that starts really high at the beginning of the day and ends really low at the end of the day. And the idea is that as the day wears on, as you make decisions throughout the day, that you lose a little bit of your energy, a little bit of your brain's power to make the right decision throughout the day. So the recommendation that has been given both by me on this show and in even academic journals is to make decisions that matter the most as early as possible. Now, given the research that Daniel Pink presented on the show, this is still not a bad idea. Making really important decisions that require a lot of thought in the mornings is probably a good idea for most people. Of course, we talked about the different chronotypes in that episode. And so maybe for you, it's that night, go and listen to those episodes to learn more about that. But the reasons that we believe ego depletion was happening may not actually hold true. And so some more recent research has come out that ego depletion is more based off of what you perceive, of what you believe about the work that you're doing. Some more specifically, if you believe that what you're doing is difficult, then ego depletion will actually be real for you. You know, actually experience that loss of willpower throughout the day as you are, you know, making part in these difficult tasks, things that you perceive as difficult. However, if you do the same tasks and you perceive them as simple, you are much less likely to lose willpower throughout the day. Now, this isn't a magic solution. You can't just snap your fingers and suddenly believe something that you were believing was difficult is not difficult. It requires a little bit of legwork and perhaps some commitment and time for you to start perceiving things differently. And we're going to talk about ways that you may be able to help kind of move that process along in today's episode. We're going to do that right after we talk about today's sponsor digital ocean. Digital ocean is providing Developer Tealisteners with a hundred dollars worth of free credit to get started on their platform today. It's the easiest cloud platform to run and scale applications from effortless administration tools to robust compute storage and networking services. Digital ocean provides an all-in-one cloud platform to help developers and their team save time when running and scaling their applications. Digital ocean is also predictable and with affordable pricing, you can leave complex structures behind. Always know what your business will pay per month with industry leading price to performance ratios and a flat pricing structure across all global data center regions. Selling and alerting is included with all of your plans at digital ocean. And of course, you can scale to any size that you need flexibly. Go and check it out. Head over to dio.co slash t a that's d o is in digital ocean dot c o slash t a for a hundred dollars worth of credit on digital ocean. Thank you again to digital ocean for sponsoring today's episode of Developer Tea. So we're talking about this concept of avoiding ego depletion by making things seem simpler. This is a complex topic because perception is always difficult to control and to talk about between different developers, people with different backgrounds, different experiences, different ways of believing about software. Some people may be able to perceive a task as simple and another person may perceive the same task as very difficult. So which one is it? Is it simple or is it difficult? As far as your brain is concerned, it's whatever you think it is. Or I guess a better way of putting that is it's whatever you believe it is. Of course, this doesn't mean that you can just start believing that writing perfect code with no bugs is easy and start doing that right away. This is more about finding tasks, finding work that is right at the edge of your ability. Right? That is challenging and approaching that work with the most effective mindset. Okay, so that's what we're going to talk about. I'm going to give you three ways to think about work that will make it seem simpler. And by making it seem simpler, it will actually become simpler. Right? It's not just about perception here. It's actually about, you know, this is the way that your mind is interfacing with the work that you do. Right? So we're going to start with a very simple one and that is committing to simplification as a standard. Committing to simplification as a standard. This is kind of a way of thinking about your work. If you're not constantly thinking about simplification, then you probably should start. You need to commit to this idea. So how do you do this? Well, for example, if you're just starting out as, you know, learning as a developer, then you need to worry less about trying to learn every language that you see that's popular. And you need to worry less about learning every programming paradigm and reading every computing book that's on the shelf and getting all the way through the art of computer programming. Instead, focus on fewer things. Focus on fully understanding a smaller group of things and only focus on one of those things at a time. It seems counterintuitive because there's so much information. There's so many ways of doing things. There's so many good languages, so many good books, good opinions, good patterns. And it seems like we're missing out if we don't learn a little bit of all of them. If we don't broaden our knowledge and try to capture all of them. Unfortunately, if we try to do all of them at once, this becomes nearly impossible for our brain to process, right? So it's a much more effective way to learn if you can focus on a few smaller items first. And then eventually grow your knowledge more like a network. As you begin to learn other things, once you've kind of established that base of knowledge, you'll be able to compare them better to the original thing that you learned, right? If you have a thorough understanding of one part of programming, then you can understand the next piece in relation to the piece that you already have context for. I think it's important to note at this point that concepts in programming are not something that you learn and then put on a shelf and move on. Concepts in programming are things that you learn and then use consistently and you take them with you as you're learning other things. So you should never consider the idea that you have something completely finished, that some fundamental idea of programming that you've got it figured out. You will find new uses and new ways of thinking about the same old topics throughout your entire career. So I want you to remain curious as a developer. Then open to learning new things, this is not about closing off those paths, but instead it requires focus and resolve not to veer off of those paths too early, not to try to follow 10 paths at once, but instead to take note of the other paths that you see along the way. Stay on the path that you've established and give it time to really flourish, give your brain time to really understand a concept before you move on to another one. Once you have a tangible experience need for change, that's the best time to respond to that need. Instead of trying to preemptively plan for those changes and try to jump tracks before you really had a chance to know if you needed to jump tracks, it makes more sense to wait until that need is much more present, much more visible. And then address the need. And this leads me right into the second recommendation that I have for you to make things simpler in your programming. And that is to plan for tomorrow, but solve for today. Plan for tomorrow, but solve for today. This particular point is a never ending conversation in development, especially if you have worked on a team that practices agile. And you have small iterations on working software. Sometimes it seems that the things that you are iterating on, you never really have a chance to take a step back and look at the big picture. At the same time, if you're always looking at the big picture, then you never really have time to take a step inward and look at the small things and prove at a step by step level. So you have to write one line of code at a time, right? Write one feature at a time. There's no other way to do development. We aren't actually implementing a large scale change. We're implementing one small change at a time. And so it's important to work in that frame of context, that kind of granularity, but it's important to understand and have perspective for a larger granularity, a larger frame. So to know where your work is headed, to know kind of what the planned goals are, can help drive the smaller level iterations, the higher granularity iterations. What this can do as you are developing is provide you with better guidelines and boundaries for decisions that you make. It provides better context, better acting context for what you're doing. What I want to caution you as you are kind of contextualizing your work, don't try to build code in preparation for a problem that you're solving tomorrow. Don't try to structure your code or scaffold out too many things before you need them. The truth is a lot of the code that you preemptively write, either ends up getting rewritten or ends up getting changed and never needed in the first place. So a lot of that energy is sideways, not to mention it makes your application very difficult to understand when you return to it. So as you're writing this extra code that you don't need yet, if you were to look at your application so much of it is kind of work in progress kind of code that's not really being used and is ultimately likely to be changed anyway. So stay focused on only one thing at a time, but don't allow that kind of zoomed in picture to give you the false sense that a zoomed out picture just doesn't exist. That's not the case, but understand that you will always be working at that zoomed in context. Lastly, our third piece of advice for making things simple is to divide and conquer. If you're used to this technique in algorithm design, then hopefully it'll come a little bit more intuitively to you. But the idea is if a concept is too difficult to understand, cut it in half, maybe a better way to look at it is take only a part of that concept, take a sub concept, take the smallest piece that you can find. And if that is still too difficult to understand, then take a smaller piece inside of that. So essentially what you're doing is you're cutting away all of the conceptual pieces that are complicating things and eventually you'll get down to a more atomic concept. So we can run through a very simple example. Let's say we want to store a list of contacts in a globally available, backed up, and resilient database and access those contacts through a authenticated JSON interface. Well, there's quite a few problems of solve. This seems like a relatively straightforward kind of application, but in order to piece this up, perhaps we start with just creating what a contact is, understanding what goes along with the contact, what are some of the fields that we might want to have in a contact. So we can start there and then begin to piece by piece, figure out the next thing that we need to understand in order to build this concept. So we create a contact model that starts out with just first name. A sustainable way to approach this that has been proven over and over is to run this through a test-driven process. So in other words, write a test that says contacts should have a first name. Another test may say contacts should have a last name. When you break problems up to these very small pieces, each of those problems become so much more understandable than the larger problem at hand. And what you'll end up doing is uncovering edge cases. For example, if a contact doesn't have a last name, or maybe they have two middle names or no middle names, maybe a contact has a nickname that's important, or they have a suffix or prefix. By focusing in on the simplest versions of the problem, and more specifically on the sub-problems inside of a given problem, you end up creating a much more clear action step. When you have a clear action step, your decision-making becomes much easier. You have much fewer decisions or options to choose from in order to make a given decision. Ultimately, in all of this, trying to simplify things and trying to shift your perception to the perspective that things are simpler than they may seem. Encourage you to remember that the first step is the most important one. Things can be much harder than they seem in our minds until we get moving, until we actually act on them. If you constantly remind yourself that the process of solving a problem includes a lot of failure, then you may realize that those failures aren't easier to bear than maybe your brain wants to tell you they are. Because of that, things become a little bit easier because you are able to work through failures. Encourage yourself that your brain is a powerful thing, and it's also a faulty thing. If you're trying to be perfect, well, no developer has ever been perfect. Instead, I want you to think about programming as a series of tiny problems. If you can focus on solving one tiny problem at a time and composing the solutions to those tiny problems in order to solve the bigger problem, then hopefully you'll start to gain this perspective that what you're doing is simpler. And instead of feeling depleted at the end of the day and feeling like your willpower is completely gone, you may feel energized by the end of the day. Focus on the problem at hand, focus on the smallest version of the problem, and don't get ahead of yourself, and simultaneously, don't look back. Don't look back at previous failures, or don't look back at how long it took for you to solve that one bug. Stay in whatever you're working on right at this moment. If you can stay with one thing at a time, simplicity will become the rule. Thank you so much for listening to today's episode of Developer Tea, and thank you again to Digital Ocean for sponsoring today's episode. Thank you so much for listening. If you haven't subscribed to whatever podcasting app you're using right now, I encourage you to do so before this episode is over. We publish three episodes a week, and it's easy to get behind, so I encourage you to subscribe so you get alerts when episodes come out. Thank you so much for listening. And until next time, enjoy your tea.