We are staying practical on this week of Developer Tea. My name is Jonathan Cutrell. My goal on this show is to help driven developers connect to their career purpose and do better works. They can have a positive influence on the people around them. And this week we've been talking about very practical things, practical application of the ideas that we very often talk about on this show. In today's episode, I'm going to explain to you why you haven't picked up that new tool. You haven't followed through on your test-driven development habits. You don't actually keep your code tested. You don't keep your documentation up to date. Perhaps you aren't following your New Year's resolutions that you set this year. How are those going for you? You know, we're in April towards the end of April heading into May. How are your New Year's resolutions going for you? How many times have you checked in on those resolutions? So what we're really talking about here's habits, informing habits. And there's some really good literature on this. There's a lot of opinion on it. And there's a lot of research on habits because habits really form the vast majority of what we do in our life. And this is no new subjects on development to you. We've talked about having useful defaults for this very reason. Defaults are things that you create habit out of. There are ways of behaving when there's nothing else to tell you to behave differently. Tell you behave most often, most regularly, without any input, without any steering, you're going to do X, Y or Z. Habits allow your brain to have a break. You have a common way of dealing with a particular situation or responding to a particular situation. And your brain doesn't have to process that. It doesn't have to make as much of a decision in that moment because your habit is kind of a automatic switch. It's your response. Rather than it being a constructed decision, a well thought out decision, your habit is an easy go to. It's kind of like a macro script that your brain runs on a regular basis. So this seems both simple and difficult, doesn't it? Isn't it hard to both do something without thinking about it, but also change your existing habits, change them for the better? It is a little bit difficult, but we're going to talk about reasons, perhaps the most common reasons why you as a developer, me as a developer, any developer and really people in general don't tend to succeed in changing their habits. Before we talk about that, we're going to talk about today's awesome sponsor, BitRise. BitRise is mobile continuous integration and delivery for your whole team with dozens of integrations for your favorite services. BitRise features automatic platform and configuration detection, build, test and deploy steps that happen in just minutes and an open source library of over 170 integrations, no scripting needed. In other words, you aren't going to have to spend extra time on that on that code base on the test suite just to get it to run in your continuous integration. You can run the same config locally that you have on BitRise with the open source command line tool by downloading the BitRise YAML file. Super simple to get up and running with this. They have a visual editor to kind of block together, like Lego blocks, the different services that you want to run in response to each other. It's a very cool concept. You can kind of think of it like if this is the NAT, the way that you build the stuff you don't have to go through the tedious process of configuring all of your testing yourself. You can let BitRise handle it. They have again a ton of integrations that they already support. Things that you are probably already using, perhaps other services that you are using for your mobile application. You can do even lower-level things like running scripts, running gulp commands or running Yarn commands or things like that. Tons of options you have available at your disposal with BitRise. Go and check it out. Head over to spec.fm slash BitRise to get started today. You can get into BitRise for sponsoring today's episode of Developer Tea. So we're talking about habits, how to actually instantiate these habits. Why is it that you can't seem to do that? You really want to have good habits. You really want to be able to say that you are a test-driven developer. Now when it actually comes to behavior change, that's the real hurdle. You have a picture in your mind of what you would like to be true. You would like to say that you're a test-driven developer. You would like to be on the other side of losing all that weight that you're still carrying around from the holidays of 2017. And you'd like for all this to be true. And it feels like just wanting it should be enough. That's what your brain tells you that imagining these things and then putting forth some kind of minor effort should get you there. That you've actually taken at least one step. And unfortunately, very seldomly, does one step towards a goal actually get you to that goal. Unless, of course, that goal is very small. And most of the things that we want to build habits around are much more long-term goals. They're more like identity goals. Things like, I want to be a good developer. And therefore, I want my code to be tested. So how can I instantiate and establish this habit so that my code is more often than not as the default my code is tested. Now the interesting thing is that there are some people who don't struggle with not having tested code. Those people very often started on day one developing good habits. They developed the habit of testing their code from day one. They saw development only through the lens of test-driven development. And if you talk to somebody who is like this, if you talk to a developer who has practiced test-driven development from the beginning, it's apparent that they don't see it as a huge struggle. That the habit itself is carrying the weight of the behavior. So what is the problem? Why can't we seem to establish habits? There's a few reasons. The first reason is even though we have some kind of state, some future states, some goal in mind of what we want to be true, we don't know what that state is composed of. In other words, we want to test all of our code, but we haven't taken the time to look at what that actually means in practice. We don't know what a day in the life of a test-driven developer looks like because we've never experienced it. We've never adopted that practice fully and therefore we can't really envision what that plan would even be. Identifying the routine that would be necessary. So it's very difficult for us to even try to establish that habit because what we end up trying to do is shove some elements of that habit or some elements of that routine in without adequate planning. This is a huge problem because usually what it means is that we have someone like myself or like you who are listening, you have a lot of energy, you have a lot of commitment, you have a lot of passion, an excitement about changing or establishing this habit, but you don't know what the habit actually entails. What is the real routine? I encourage you. I challenge you right now, take the two or three minutes. You're hopefully thinking of a specific habit that you've wanted to establish and you haven't been able to take two or three minutes to sit down and write out what the routine is. Now most likely this is going to be hard because you don't know what it is. It may take a little bit of reasoning and perhaps more importantly, it may take some research. You may need to go and look at successful test-driven developers, for example. What is their routine? What is their investment strategy look like for actually spending time on writing tests first? What behaviors and more specifically what stack and order of behaviors does someone who is successfully implementing this particular habit? What are they following? Learn from someone who's already done it and then try to emulate that. Of course, it's going to be a learning process and all you're doing by taking somebody else's thing, taking somebody else's success is you're trying to learn from the elements that apply to them and then essentially steal those ideas for yourself. That seems very simple, it seems very obvious. It seems clear that if we don't know what the routine is then how is it possible to even establish it? There's probably some kind of lie that we believe that we're going to stumble our way into that routine accidentally. That just out of sheer will or desire and energy when we combine those things that somehow we're going to magically stumble on that routine and that very rarely happens if ever. Usually the routine has to be learned and then subsequently applied. That is reason number one. Then the second reason we're only going to go over two of these today. We're going to keep this episode short. The second reason that we so often fail at establishing habits is that we are not reinforcing our habits with the right kind of reward. Very often we believe that our desire and achievement is enough of a reward to continuously seek after establishing the habit. This is not true because we are not going to establish a long-term goal on day one. So day one, therefore, doesn't have the reinforcement of a reward. Knowing that you met your self-expectations is some of a reward, but it's not enough. So we need to structure our routines to provide us with a tangible and present reward. Now hopefully this is not something that's going to be antithetical to another habit that you're trying to form, for example, and if you're trying to lose weight and you eat well, then you shouldn't reward yourself with bad food, of course. But instead you can choose something like allowing yourself to do your favorite exercise at your next workout. So this is a both a healthy habit, a healthy reward, but it also gives you a direct kind of signal, right? Your brain receives the signal and it connects the reward to the action. At the most basic and stincuial level, this is how we train our brains. If we provide ourselves the right kind of incentives, and we are consistent in how we apply those incentives, and the incentives are scaled to the routine, the effort that is necessary to earn them, then we will continuously reinforce the good habits. Some very simple examples of incentive might be allowing yourself a extra two minutes on your five-minute break, right? Allowing a longer walk in the afternoon or perhaps something as simple as giving yourself a trip to the movies at the end of the week if you maintain your habits throughout the rest of the week. And these incentives are going to vary from person to person. Some people would not respond well to that particular incentive. So you need to configure it for yourself. And remember it doesn't have to be a huge incentive. In fact, it's probably better if it's scaled to the routine. So losing ten pounds probably shouldn't earn you a vacation abroad, right? That's not really an equalized scale. Hopefully this episode has been enlightening about why your habits may not be sticking like you had hoped they would. There's more content about this subject in Charles DuVick's book The Power of Habit. Go and check that out. My name is Jonathan Cutrell. You've been listening to Developer Tea. Today's episode was sponsored by BitRise, the continuous mobile delivery platform that allows you to integrate with over 170 different integrations. Go and check it out, spec.fm slash bitRise. Thank you so much for listening and until next time, enjoy your tea.