I've ever tried to understand what a fourth dimension would be like. This seems almost impossible, of course. We don't experience four dimensions. We experience three dimensions, and these spatial dimensions. And it would be very hard to explain what a fourth dimension would be like, and specifically how it would feel. And so perhaps the best way to understand how a fourth dimension would feel is instead to imagine that you are living in a two-dimensional world, and then you have a third dimension added. Even though it sounds like we're going to be talking about dimensions and physics in today's episode, we're not talking about that at all. In fact, we're still talking about problem solving. This is the third episode in our problem solving series here on Developer Tea. My name is Jonathan Cutrell. My goal in the show is to help driven developers connect to their career purpose and do better works so they can have a positive influence on the people around them. And although it's a fun discussion to have about dimensions and how you can imagine a world in two dimensions rather than three, and then the kinds of things you may do to simulate adding that third dimension, that's not what we're talking about. What we're talking about here is trying to gain a new perspective and why it is that it's so hard to do that. You can probably recall multiple problems that you've tried to solve, whether they are in code or if it's an interpersonal problem or a business problem, maybe a marketing issue, something like this, that you are trying to solve and you're deep in the problem and you seem basically stalled. You can't move forward. It's the equivalent of writer's block, but for problem solving and there seems to be no way out. But you know theoretically that pretty much any problem that you're going to have interpersonal or in business has some kind of solution. There is some way forward. And so you continue grinding away. You continue looking at the problem and you continue being stuck. In many ways this is similar to brute force learning or trying to memorize something through repetition. You keep on trying to add this thing to your brain or you keep on trying to take a step forward on this problem and you may have very small incremental progress, but it seems like the rate of progress is slowing to a complete halt. And sometimes it even seems like you're going backwards, like you're making the problem worse than it was just a few minutes ago. What causes us to do this? There's no perfect answer to this question, but we've all experienced this feeling of not seeing the forest for the trees. We're in the problem and we're so deeply influenced already that we can't approach it from a new perspective, we're kind of already poisoned with the knowledge that we have. So how can we break out of this? That's what we're talking about in today's episode. And I'm going to share a few tactics that you can use to kind of zoom out and hopefully shift your perspective a little bit right after we talk about today's awesome sponsor, Linode. I want you to think about something that you pay a dollar a day for, something that's $30 a month. And then I want you to think about something that you pay 50 cents a day for, be something like 15 bucks a month. Now I want you to try to figure out if you pay 20 cents for anything per month. The answer's probably not. And in fact, Linode will cost you even less than that. You can get started with Linode for only $5 a month, that's 17 cents a day. It's actually a little bit less than 17 cents a day. This is such a no-brainer investment, especially for new developers on this $5 a month plan. And if that's not affordable enough, Linode is going to give you $20 worth of credit, which is equivalent to four months worth of service on this $5 a month plan. And with the $5 a month plan, you get a gigabyte of RAM. You get access to the 40 gigabit internal network. The storage for your server is entirely built on SSDs. And customer service at Linode is 24.7. There's so many other options that Linode provides. And it's not just this introductory plan that Linode has. They have support for the largest application that you can imagine building Linode can support. They have high memory plans. They have extra tools for developers because they are developers. So they understand things like mocking yourself out of your server accidentally by screwing up a config file. You may have gone to your server backup and restored your entire server, but with Linode you wouldn't have to do that. You can just use the special tool that they have to allow you back into your server without that config file being correct. There's a lot of other things that Linode offers that we can't get to in today's episode. I encourage you to go and check it out. Spec.fm slash Linode. And you can get started today. Remember $20 worth of credit for using the code Developer Tea2018. That's all one word. Spec.fm slash Linode. Thank you, Ginalinode, for sponsoring today's episode. So when you're trying to change perspective in order to solve a problem, there's a few different tactics that you can use. So I'm going to share a couple of them with you today. The first tactic is to move the problem. What does this mean? Well, imagine that the problem is not yours. Imagine that it's someone else's problem. And you are coming in as the benevolent friend that you are, or maybe you're coming in as a higher consultant, and you're giving them advice on how to solve that problem. Suddenly, the way that you see the problem, it starts to break some of the bias that you have around the problem. Or at least it's going to highlight some of those biases. So where you previously were perhaps affected by sunk cost, where you feel like you've put a lot of time into this one particular path, and you really want to find the solution in that path. If you're a consultant, you wouldn't really care how much time has been put into a particular path. All you really care is that the problem is solved. And so you may be able to break away from some of those biases that affect your ability to decouple yourself from some sunk cost investment. So move the problem. This is essentially what you do if you engage in the practice called pre-mortem, where you try to imagine what failure would look like before it happens. So you're trying to identify the likely weaknesses in a plan. This is a very similar practice because it changes the perspective, the positioning of your perspective away from a kind of arduous work oriented, I'm the problem solver kind of perspective, and towards a more observational perspective, someone from the outside looking in. So move the problem. If only in your imagination, move the problem so that you can approach it as an outsider, rather than someone who has got to been toiling away at trying to solve the problem. Another tactic, and this one is probably something that you could see coming, explain the problem to someone who has no knowledge of the domain of the problem. So if you're a web developer, explain the problem to someone who isn't involved in web development at all. If you are trying to solve an interpersonal problem, this may be a little bit more difficult, but explain the problem to someone who doesn't know the people that are involved. When you start to explain the problem, you're having to communicate some more foundational things that you otherwise may have taken for granted that aren't necessarily in the front of your mind when you're evaluating the problem, but may be important to your problem evaluation process. This is one of the reasons that mediation often helps significantly when you have two people who have conflict. Because a mediator may have no knowledge of the previous history, they haven't kept a score, they don't know if one person is more often acting in a particular way, or if the other person more often acts in their particular way, they only know what you're telling them. And so for a given situation, a mediation process, it may really help. This is true in other types of problems as well, not just interpersonal conflict, but very generally speaking in almost any kind of problem solving context. If you kind of return to a foundational point, return to the basics of the problem you're trying to solve, and reiterate from the basics kind of a foundational approach and build the problem from that foundation. This is also kind of related to duck debugging, where you walk through your code, one line in a time and explain what each line does. Very often our blind spots come from assuming that the line that isn't producing an error, for example, can be glossed over. But when we intentionally refocus our brains on explaining every single line, on returning to that foundational aspect, the kind of core, right? When we try to explain our problems to someone who is totally unaware of the domain, we may rediscover some relevant aspects of the pieces, the parts of the problem that could be exacerbating the problem without us even realizing it. And those blind spots that we have, we may be taking a spotlight and shining it directly on one of those blind spots. All right, so that's tactic number two, explain the problem to someone who has no knowledge of the domain of the problem. And finally, tactic number three, visualize the pieces and parts of the problem in a new way. Visualize the pieces and parts of the problem in a new way. So if you're working on a problem that is centered on, for example, a particular data structure, like an array, then change the data structure. Imagine how the problem will be solved with a different data structure. For example, you could shift from an array to a heap. Now it's not necessarily the case that you're going to stick with a different data structure, right? You're not going to use this visualization necessarily in the long run, but rather you're trying to explore the problem from different angles. Now the more visual you can make this, the better. But if you can draw out what you're trying to explain on a whiteboard or if you can model it, for example, using different colored post-it notes, right? There are a lot of ways that you can visualize your problems. And suddenly something that wasn't apparent before becomes apparent now. You can do this in a lot of different ways. Again, of course, making something visual, you can use different modeling techniques to do this, but you can also model your problems through the lens of a metaphor. Now we've talked about metaphors and the power of metaphors in the past on this show. I encourage you to go back and listen to that episode and also look at other examples of metaphors in computer science history. They're all over the place in computer science because so many of the problems that we solve as developers, really they are virtualized, right? So we're writing code and we're having to construct in our minds or in some physical tool like paper and pen, we're having to construct what the meaning of these various problems is. And it can be especially hard when you are brand new to a problem or perhaps the naming structures and the project you're working on are suboptimal. And you're trying to wrap your brain around what's happening, what is causing this problem, what are the pieces of this problem, how should this thing behave? If I looked at it differently, what would it look like? If I flipped the problem on its side, what would it look like? And the more physical that you can get with this, the more visual you can get with it, the more likely you are to effectively change your perspective in a way that illuminates something that you didn't see before. And metaphors provide you a way to understand something that you've experienced in the past in a much more tangible way. You can kind of map your program, your software to the concepts that you physically experienced previously. This is why we use metaphors to name various aspects of computer programming. For example, trees. It seems like it's a core fundamental concept, but in fact, it's a metaphor. It's a metaphor that we use to understand something that is virtual. I encourage you to watch out for these metaphors and to lean on them when you can to create a more physical representation that you can map these virtual concepts over because the more you can conceptually envision the problem space, the more likely you will be able to shift that perspective. Thank you so much for listening to today's episode of Developer Tea. It was our third episode in this problem solving series. I encourage you to go back and listen to the first two episodes in the problem solving series. If you don't want to miss out on future episodes just like this one where we talk about things like problem solving and cognitive bias as it relates to programming, I encourage you to subscribe in whatever podcasting app you're using right now. Now if this episode or any other episode has been valuable to you as a listener, then you can help give back to the show by going and leaving a review in iTunes. This is the best way to help other developers just like you to find Developer Tea. Head over to iTunes, leave a review, leave a rating, that's super helpful. Thank you so much for listening. Thank you again to Leno for sponsoring today's episode of Developer Tea. Leno is giving you a $20 bill. Head over to Respect.fm slash Leno to use the code Developer Tea 2018 at checkout. The most no-brainer investment you can make as a young developer. And of course, if you are developing a large scale application, Leno has you covered as well. Thanks for listening to today's episode and until next time, enjoy your tea.