I can, I must, and I will. This is a quote in an email from a listener, and I'm actually super excited about this episode. I received this email in response to a previous episode about systems versus willpower, and this is kind of a motivational quote that unfortunately, once our willpower runs out, it doesn't really have a lot of power over us, does it? My name is Jonathan Cottrell. You're listening to Developer Tea, and today we're going to talk about a specific way of creating a system, right, creating a system that will stand in place whenever your willpower is not available, and that's what we talked about on that episode, systems versus willpower. Make sure you go and check out spec.fm if you want to find out more and listen to that episode. Of course, there are show notes on spec.fm as well, so go and check that out. I'm going to go ahead and read this email, and then we're going to jump into how you can create a system to stand in place. We're going to use some specific examples on how to create a system that stands in place when your willpower fails. This email comes from Kan Chi. I hope I'm saying that right. Maybe Kan Chi. I apologize if I'm mispronouncing your name. Kan writes in and says, Hello, I have been listening to Developer Tea for the last year, and I've been really enjoying them. You have quality content in each episode. Your tips are great, not to mention your reviews, which are wonderful. Thank you for doing this. I appreciate it, and I've benefited from it. I'm writing to you to give specific feedback about your recent episode on willpower versus systems. Your opinion about willpower as a scarce commodity is very true. All these I can, I must, and I will kind of motivation messages only work for a certain time, as you rightly mentioned, that willpower depletes and people are back to their old selves. Your example about exercising was apt. Can you do a follow-up episode giving some specific tips on building such a system? Again, thank you for your podcast. Keep them coming. Sincerely, Kan. Kan, thank you so much for writing in, and I have to express just a huge thank you, and I'm always humbled by these messages that talk about the value that people are getting out of the show, especially over the course of the year. I'm so grateful to be able to be here today. I'm so grateful to be able to be part of this course of as long as a year. We've been around for just over two years, about two and a half years now, actually. It's always so surprising and exciting to be able to provide value to those of you who listen to this show. Thank you so much for writing in. It gives me so much fuel to know that I'm helping someone who's listening to this. Thank you. Yes, absolutely, we're going to talk about how to build a system that can help supplement your willpower. We also have to address this idea that motivation is somehow going to increase your willpower. It won't. Willpower is much more of a physical process than we really want to intuitively believe. And our brains are actually depleted of energy. We actually are trained to not make too many decisions because decisions are hard. And so making decisions over and over and over in a given day, really, it's not about having the motivation to make another decision. It's about losing the energy, right? It doesn't matter how motivated I am. Let's take this to the extreme. It doesn't really matter how motivated I am. I can't be motivated enough to never sleep again, right? Because that's a biophysical thing that has nothing to do with the energy that I'm having. And so I'm not going to be motivated enough to never sleep with the motivational messages that I'm receiving. So motivation certainly has its place. There's some very interesting studies on, for example, the motivating effects of music whenever you are exercising. So really interesting stuff on the effects of motivation. But if you try to rely on motivation for the primary driving things that you do in your life, if you try to rely on motivation, for example, to build a habit, it's likely to fail. So that's why we need to create these systems. And we're going to take a quick sponsor break, talk about today's incredible sponsor, Linode. And then we're going to talk about how you can create a system. What does a good system look like to stand in place when your willpower simply fails? We're going to talk about that in just a second. First, let's talk about today's sponsor, Linode. Here's the big story. Linode is providing you almost double the RAM on your Linux servers that other people are providing, that competitors are providing at the same price brackets. So if nothing else sells you on Linode, that right there is enough. Because most of the time, the things that limit you on a given server are probably going to be related to memory before they're related to the CPU performance or before they're related to the storage on that server. Now, with that said, Linode also provides great storage options for your Linux servers. So if you're a Linux server, you're going to have to have a lot of storage options. And their CPUs are their Intel E5 processors, right? And it's on top of SSDs. So everything on Linode is going to be fast. On top of that, you get that added bonus of doubled RAM for the same price as the competitors. So they have eight data centers. Their plans start at $5 a month now, okay? Not $10 a month like it used to be. It's $5 a month, and that gets you a gigabyte of RAM for $5 a month. So that's a lot of storage options. And they're going to have to $5 a month. That's $60 a year. On top of that, Linode is offering you $20 of credit just for being a developer tea listener. Go and check it out. $20 of credit. That's $40 for a server for a year. I can't imagine a better investment that you can make as a developer, especially if you don't yet have a personal site. $40 for your own server where you can host a personal site, a gigabyte of RAM. That's a fantastic deal. So go and check it out. spec.fm slash Linode and use the code developer tea 2017 when you check out. That's developer tea 2017. All one word. Thank you again to Linode for sponsoring today's episode of developer tea. By the way, Linode is offering two gigs of RAM for only $10 a month. So if you if the one gig plan is not powerful enough for you, then two gigs is only $10 a month. So still a fantastic deal with the $20 of credit. They're offering that's $100 a year, or at least for the next year. So go and check it out again, spec.fm slash Linode. Thank you again to Linode for sponsoring today's episode. How do we create systems? How do we create a system? Or better yet, what does a good system look like? A system that can stand in place when our willpower fails. We're going to talk about three characteristics of good systems. Three characteristics of good systems. And you can walk away with these characteristics if you implement a system in your own life that has these three characteristics. I want to be very clear. We're talking about systems of habit or systems of personal action, things that you do to plan your days and ways that you can plan your days that when you fall back, the useful defaults concept, the positive defaults is hugely important here. So if you haven't heard of that, Google around. We've done an episode on the subject of useful defaults, specifically with relation to your habits. Again, go back and listen to the episode that this one is in response to about systems versus willpower. There's a lot of good information in there. But we're going to talk about these three characteristics. Characteristic number one, good systems have contingency plans. Good systems have contingency plans. Do you know what a contingency plan is? If you don't know what a contingency plan is, quite simply, think of it like this. Your code typically has contingency plans in it, right? Good code has contingency plans of when something goes wrong or when an exception occurs. Basically, we're talking about conditional plans that allow for flexible and changing scenarios, contingency plans. If this thing occurs, or if this expected situation turns into an unexpected situation, your system can't be so brittle that it suddenly doesn't apply. So a good example, we're going to use exercise. Once again, this is such an applicable concept. If you have a system that says, I will exercise every day for a day, your system, if you rely on that idea that you have to exercise at the gym, if the gym closes for the day, then your system no longer is accomplishable, right? We're going to talk about making accomplishable systems in just a moment. But instead of making the gym a part of your system, you make the gym the optional part of the system, right? You make it so that if the gym is closed for the day, then your system is no longer accomplishable. So if you have a system that says, closed, you have a secondary place that you know you can go to exercise. We have this in our home. I have a bike that's on a training rack. And now I do a lot of my exercising at home, especially when we are time constrained. That's an example of an exception. When we are time constrained, it's easy to make those decisions off the cuff that we're not going to go to the gym. So if I'm in a room that's a little bit brittle, if I required the gym in order to exercise, then I wouldn't exercise, right? You see how the failure is kind of a binary failure. Really, what you want to have in place is plans for when things go wrong or plans for when things go unexpectedly or ways. And this is the second point, really. Ways that your system can be, number two, adaptable to scale. Adaptable to scale. Well, what does this mean? This is a very special kind of contingency plan, perhaps the most common kind of contingency plan. And that's when your time is shifted, when you have some unexpected thing come up and now suddenly your system has to accommodate a different scale of time than you originally planned. Here's a very simple example. My wife and I recently, we've been getting our home ready for our child. We've been getting our home ready for our child. If you haven't heard, we're having a child arrive in June here at the Cottrell household. And we've been actively getting our home ready. There's a lot of stuff that we have been carrying in our closets and a bunch of junk that we have in rooms that we really don't need anymore. And it takes some time to sift through that stuff, right? So if your system for keeping your closet clean is to clean the whole closet, well, if you have a closet like ours, that could take a while. So if you have a closet like ours, that could take a while. So if you have a closet three days worth of work. And the problem is 100% about the scale, because the reality of what you're trying to do is clean the closet, which happens one step at a time. So if instead, your system is built with the concept of scale in mind. So instead, if you say, we want to actively clean our closet for whatever time we have available up to 30 minutes, then we're going to have to clean the closet for whatever time we have available up to 30 minutes every Saturday. That seems doable, right? And actually creating a system that can scale with what you have available in terms of time or resources, that is a system that is much more likely to succeed than one that requires a minimum scale that makes it effectively and feasible for you to accomplish. And that's our third aspect of any given good system, and that is that it is comprehensible and accomplishable. Comprehensible and accomplishable. So we talked about systems versus goals, right? And how goals are less specific than they need to be, and they rely primarily on willpower. But when you create a system that moves you towards that goal, then that's a much more likely scenario for success. However, it's possible for you to create a system that is just as incomprehensible as a system that is just as incomprehensible as a system that is just as incomprehensible or just as unaccomplishable as some of your goals are. So for example, if you take our first aspect, our contingency plan aspect of a good system, and you run too far in one direction with that, and you have 500 contingencies, the complexity of your system is now going to be nearly disabling to you. Creating a much simpler system, with a few contingencies, in the most likely scenarios, you are much more likely to be able to comprehend that system and apply it automatically whenever the scenario arises for you to apply it. And in the same way, if your system is not accomplishable, right? If your system requires something of you that is infeasible on a regular basis, then your system will fail. This seems obvious, but let's go to a coding example. If you require for all of your projects to have 100% continuous integration and to be reviewed by three people every single time you push any kind of code, and there's never any exceptions to that rule, there's no contingencies, none of that is accepted, well, your system is much more likely to not be adopted, right? It may be thrown out entirely. If instead you create a flexible system that includes a lot of the same things that you do in a previous system, then you're going to have a lot of problems. So if you require for all of your projects to have 100% continuous integration and to be reviewed by three people every single time you push any kind of code, then you're going to have a lot of problems. So if instead you create a flexible system that includes people to follow continuous integration, it encourages developers to come and review your code, and it has a scale rather than a hard line. In other words, you could have one review, but it's encouraged to have two or three reviews of your code. This flexibility in your system allows you to still follow a system, to still have guidelines, but for the passing nature of your actions, for you to be able to implement or to execute on this system without it being restrictive and without it being nearly impossible to actually accomplish on a regular basis. And all of this stuff is going back to the fact that we are trying to create systems in our lives, we're trying to create predictability in our lives, we're trying to create ways of thinking that unify our efforts. And point us in more predictable directions. We're trying to create these systems on a very uncertain reality. That's our basis that we're working from. And so good systems recognize and make provision for uncertainty. I hope that this has been useful to you, Khan. Thank you so much for writing in your email. And if you're listening to this episode, and you're interested in learning more about these systems, please feel free to contact me at khan.com. If you have any questions, topics, or you'd like to ask a question, you can always reach out to me directly at developerT at gmail.com. I'd love to start a conversation with you. Thank you so much for listening. Thank you again to Linode for sponsoring today's episode of Developer T. Don't forget, you can get a server for $5 a month that runs Linux. You get root access to these servers. You get $20 worth of credit for using the code developerT2017. That's developerT2017. Whenever you check out, go to spec.fm, slash Linode to learn more about what Linode has to offer to you as a developer. Thank you so much for listening to today's episode of Developer T. Don't forget to subscribe in whatever podcasting app you use. And until next time, enjoy your tea.