Most of the changes that you make as developer both to code and to yourself are incremental changes. The idea is one that we connect with as developers because it works most of the time. When you make an incremental change, the difference between the new thing and the old thing is small. This means that you are of course correcting at a very high degree of accuracy. Perhaps more importantly, you can fit the whole change and the motivation for the change in your head, all as a single complete thought, usually. And even if the incremental change is a series of incremental changes, we are looking at different scales of increments. You can still imagine what is the main idea of the change from where it was to where it went. But there are times when incremental changes are just not enough. They are not effective. We end up in a local maximum. Maybe we are making things better in one area and then making them worse and another. And then we make a change and that same flip flop occurs again. In today's episode, I want to talk about a different kind of change. We're going to talk about a entire shift in the way that you're approaching something, an entire shift in the way that you're thinking about a problem, a situation, about your career, about your life, about your job, whatever it is that you are looking at. Out of updating those beliefs incrementally, we're going to look at ways that we can insight our brains to think at a scaled level, to approach a different perspective entirely. My name is Jonathan Cutrellng. You're listening to Developer Tea. My goal on this show is to help driven developers connect to their career purpose and do better work so they can have a positive influence on the people around them. When you look at your code and you find a bug or maybe you find a performance issue, the first thing that you're thinking, if you're like me and like most other developers, is how do I fix this? Where can I go in the code and change things in a low effort way to keep things mostly the same to not shake the entire system up, but just patch this one problem. Make the app work the same, but faster. Make the app work the same, but with this one functionality piece that wasn't working, now fixed. And it makes sense why we do this. When you have a series of changes, a series of evolutions, and you found something that is valuable. Then departing from that wildly for the sake of a small fix, a small change, that departure makes a lot of assumptions. That departure is much more dangerous. On top of that, you can add on the fact that as humans, we are two things. Then always seeking some levels of stability. And two, we are averse to spending extra energy, spending more energy than we really need to. So it shouldn't be surprising that we approach problems this way, that we don't want a lot of things to change, and we don't want to put a lot of energy into those small changes. The result of this kind of thinking and approach to solving problems and making improvements is that we end up often making those improvements at a linear pace, or even worse, we slow down. We slow down in our improvement over time kind of ratio. And so software, instead of going at this really high rate of improvement and value delivery, we slowly grind almost to a halt. This is a display of the concept of diminishing returns in action. The more time you spend making incremental changes to a thing that already exists, the more likely that those incremental changes are adding less value to whatever that product is. And so we have to understand when we need to be thinking non-iteratively. We need to understand when we should be thinking outside of this incremental change and instead towards a different way of thinking. This is incited by new questions that we ask ourselves. A lot of times we respond to implicit questions. For example, we see an error and the implicit question is, how do we fix this error? But there are different levels of thinking, there are different ways to think about even something as simple as getting an error. We're going to talk about those ways of thinking and some of the questions that you can start asking and really it's more a style of question that you can be asking to break out of incrementalism when you need to. But first let's talk about today's sponsor. Today's episode is sponsored by Linode. Linode is a longtime friend of Developer Tea and spec. With Linode, you can instantly deploy and manage an SSD server in the Linode Cloud. You can get a server running in just seconds with your choice, a Linux distribution, resources, and node location. By the way, there's 10 data centers worldwide and they have new data centers opening in India and in Canada before 2020. The plans started just $5 a month. $5 a month gets you started on Linode. That gets you a gigabyte of RAM. They have high memory plans. If you're on the other end of the spectrum that started 16 gigabytes, they have hourly billing with a monthly cap on all of the plans and on the add-on services. Their internal network and all of their hardware is excellent. It's all native SSD storage, 40 gigabit internal network, all running on top of Intel, E5 processors. You can do things like spin up your own VM for full control. You can run Docker containers because it's Linux, right? This company is a group of Developer That are making a product for developers. Of course, they have more than developers working there like any good company, but it's a developer centric company. That's why they are sponsoring Developer Tea. That's also why they're going to give you $20 worth of credit when you become a new customer. Go and check it out. Linode.com slash Developer Tea. We've got a new promo code for 2019. Hopefully it's not so surprising. Developer Tea2019. That's the promo code. Developer Tea 2019. Use that at checkout to get $20 worth of credit. If you're doing the math, that's the equivalent of four free months on that entry tier. That one gigabyte of RAM, $5 a month tier. You can get that $20 worth of credit by going to Linode.com slash Developer Tea and using the code Developer Tea 2019 at checkout. Thanks again to Linode for sponsoring today's episode of Developer Tea. So there are times that we need to break out of our incremental thinking, incremental improvement thinking. What are some of these times? Well, a good example of this is when your code base has grown to the degree that you need to change the way you think about the code base. Perhaps the symptoms could be that you're trying to add features and your ability to add features is slowing down drastically. This means that there's not going to be a simple incremental change that's going to fix that problem. You need to look at the problem differently. Instead of thinking about the problem from the perspective that you can fix it with one or a handful of incremental changes, you can instead look at the problem from the perspective that you and others need to shift your thinking. When I say shift your thinking, I've said that a few times, shift your perspective. What I mean by that is we have to change those implicit questions, those easy to ask questions. We need to replace them with explicit questions. In other words, you're not going to be able to change your implicit questions very easily. This is something that comes to us automatically. It's kind of our reactive state. We have to be aware of that reactive state, but then we can replace those questions. Instead of saying, what is the easy way? What is the shortest path to fixing this? How do we fix the same thing so we can instead of spending an hour to do this simple change, we spend 50 minutes and then we spend 45 minutes. Instead of asking those kinds of questions, we need to ask new questions. Here's the form that those questions are going to take. You need to change the metric so drastically in the question that it forces whatever your original mode to change. It forces the solution, the way that you're thinking to shift. Instead of saying, how can we develop this feature 10 minutes faster? How can we develop it just incrementally, 10%, 5%, a little bit faster? How do we do that? Change the question to, how do we develop this 10 times faster? Of course, sometimes these questions can get ridiculous. We could say, how do we make money by not doing anything at all? Sometimes the questions are not very useful, but a lot of the time, this thinking exercise that this produces on its own can lead you to better ways of thinking about problems. I'll give you a simple example that just happens to work out and has become somewhat popular in the last couple of years. Imagine that you are creating your own blog and in order to create that blog, you've used some kind of system like, let's say, WordPress. You install WordPress and you're running it. You've created some posts and they're all online. Everything is going smoothly, but then your server has some kind of vulnerability. Everything happens in the network, somebody hacks into your server and because you're running a database, because you're running PHP on that server, they're able to screw up your site. For, let's say, 24 hours, maybe you go on vacation and it's up for a week. You have a site that has injected content that you never wanted in the first place. The incremental way of thinking would be, well, how do we patch up this vulnerability? How do we avoid this problem that we've had and everything remain just as it was? Because everything was fine, right? This is a totally valid way of thinking about problems most of the time. But a shift in viewpoint would be, how can we ensure that we never have a problem with this again? How can I be sure that my content will never be corrupted again? Of course, the answer is you can't be sure of that because even at the flat file level, if your server is compromised and somebody can go in and write the file, so we aren't going to be able to get to a 100% solution, but perhaps we can cut out some of the main problems that we're facing here. Maybe we can rely on fewer technologies. And ultimately, we know that the site serves up as HTML and CSS and JavaScript. But if we were able to just always launch only those files, then there's not a database, there's not a language like PHP. None of those vulnerabilities, those attack factors would exist anymore. We would just have a static site. And on top of this, we get other benefits. Right? We get the benefit that it's going to be faster, et cetera, et cetera. Of course, there's going to be trade-offs. These are the kinds of things that you have to weigh when you're making these prospective shifts. And most of the time, the prospective shift will come with a list of trade-offs. And it's important to weigh those lists, to understand what you are trading for what you're getting. And in that specific example, there's plenty of trade-offs to consider. But the reality is that you have the ability to create new ways of thinking, new ways of thinking about the same problems. And this is ultimately one of the more innovative ways that you can solve problems by changing the question altogether. Some other types of questions that might create a prospective shift, a difference in the way that you think at a fundamental level about a particular problem might be, how can we make this totally automatic? In other words, how can we stop having to do this work both now and forever into the future, while still getting that work done? Another category of examples is the growth and the diminishment categories. In other words, you want to grow your income. A lot of the time, we're looking to grow it by 100%. But imagine what you would have to do to grow it by 1000%. Similarly, diminishment, if you had to reduce your turn by 2%. Well, how could you ensure that you're reducing your turn by 20%. Another way to shift your thinking out of the normal implicit question mode is to pick up the problem and take it to a different context. There's many different ways to do this. You can take the problem to an older context, right? So imagine a version of the problem, but rewind in time to 50 years ago. You could take it to a different cultural context. Imagine a different country or maybe even a different group of people, even a subculture, a different subculture context. So taking the same problem that you're facing on your team inside of the company and present it to another team inside of the company. One of the most powerful exercises in this category is the premortum. The idea here is to fast forward through whatever the thing is that you're trying to do, whatever event, maybe you're fast forwarding through a product launch and six months past the initial launch date and you're trying to figure out, in this case, with the premortum, you're trying to figure out what went wrong. What did you do that killed the product? Some other ways of thinking a little bit less implicitly and more explicitly try using a blacklist. So a blacklist in this scenario is a list of words that you can't use when you're describing the problem. Now, of course, this isn't something that's supposed to be used permanently and this isn't the same thing as an exercise in political correctness. Instead, this is an attempt to trip your brain out of the automatic thinking that it's in. And very often you'll find that you use the same words to describe something. And sometimes there's a lot that's packed into that word. And if you were to unpack it, maybe that would shift, that would bring that mindset out of that incremental thinking and force you to look at some of the underlying mechanisms of what you're talking about. We've talked about the next technique quite a few times on the show. The five wise, some people do more than five, some people do less than five. And finding a common ancestor up the tree when you start asking why. This is a way to find common ground with people, but it's also a way to say, are there other pathways that we could explore? So if you ask, why did we use, let's say JavaScript? One of the wise may be that we have good community adoption. There's a vibrant community working around it. Well, if that's true, are there other languages that have vibrant communities? Of course there are. So this presents to you some answers to the same questions, the same motivations that would have been similarly valid. And this allows you to explore different ideas. This is not licensed to go and say, hey, we need to change our entire language at whatever company you're at. But instead, we have to realize that most of the decisions that we make are so abstracted from the reasons that we make those decisions that very often we're not even seeing the multitude of other options that would suffice. Right? So think about it in terms of motivation. Think about things rather than in terms of satisfying that lowest level question, start asking the next level up. And this isn't just about becoming more productive, becoming more creative, becoming better as a programmer. This is also about you implementing change in your own life. If you know that you're engaging in some poor behavior, like for example, you're working way too late, but you feel like you can't escape it. Start traveling up and understanding what your motivation is and trying to find a new way of thinking. Why are you working too late? Well, because I feel that I need to finish this project quickly. Why do you feel you need to finish it quickly? Well, I feel that if I don't finish this project quickly, then I'll somehow be looked at as less than valuable at work. Now you're starting to get to a root cause. You're afraid that you're going to look like you're not valuable at work. And so you're responding with a bad solution. Is there another way that you can respond to that same problem that is healthy? Interestingly, some of these same ideas apply beyond just self improvement. For example, we've discussed cognitive behavioral therapy on this show before. And it shares some qualities with what we're talking about here, replacing some of our implicit questions that we find easy to answer quickly and instead interrupting that process, adding in some better explicit questions. I hope that you get a chance to try out this technique. You can do it in so many different areas. It makes it sound like on this episode. We've kind of made it sound like these are only for those big changes in your life, but you can think this way as an exercise. You can think this way to, for example, set goals for yourself. You can think this way. Let's imagine that this weekend you have plans to clean out your closet. You can think about cleaning out your closet in a totally new way and it doesn't have to affect everything in your life at a macrocosmic level. You don't have to throw everything out. It's not a major change. It's a difference in the way that you parse the problems that you face. Thank you so much for listening to today's episode. Thank you again to Linode for sponsoring today's episode. You can get $20 worth of credit. Head over to Linode.com slash Developer Tea. Use the code Developer Tea 2019 that's Developer Tea. 2019 at checkout for that $20 worth of credit. Developer Tea is a part of spec. If you're a designer developer and you're looking to level up in your career, head over to spec.fm to find other podcasts and content that is created just for you. Today's episode was edited and produced by Sarah Jackson. Another huge thank you to Sarah for making these shows sound so great. Thank you so much for listening and until next time, enjoy your tea.