Often the problems that we are trying to solve are not actually singular problems. This is true both in our code and in our relationships, our kind of software problems, career kinds of problems, typically when we face some kind of adversity, whether that is some kind of technical adversity or some kind of cultural adversity, it's not so simple. There's not a single issue that we're trying to solve but rather a host of issues, a handful of them. In today's episode, we're going to look at a way to make your problems easier or at least try solving them in an easier way. My name is Jonathan Cutrell and you're listening to Developer Tea and my goal on this show is to help driven developers find clarity, perspective and purpose in their careers. Today's episode is a little bit shorter than our average episode so we're going to go ahead and talk about today's awesome sponsor, centri.io. Centri is going to help you find issues in your code and here's what I love about Centri. Instead of taking the normal view that we should always find issues on our code before it gets to production, Centri approaches things from a higher leverage position. When you have real users using your application, you're much more likely to find problems that you couldn't simulate in the first place. These kinds of problems come from a wide variety of reasons, for example, erratic user behavior or just strange environments that users may have. For example, there's some internet service provider in a state across the country or a country across the world that's blocking some of your assets and there's no way for you to know until you get into production. How do you deal with this kind of issue and how could you ever test for it? It would take a ton of time, effort, money, resources, whatever you want to call it. There's a lot of energy going into trying to cover all of those cases or you could rely on that production environment to do that for you. That's what Centri allows you to do. Centri catches issues in your production code before all of your users see them. So you'll get alerts and you can deal with the issue immediately rather than three months down the road when a bunch of your users have already left. Thanks so much to Centri for sponsoring today's episode. Go and get started today at centri.io. Every problem that you solve in your code or in your career, in your life, every problem that your team solves or that a country solves is necessarily contextualized with other problems. There are multiple factors to consider and there's really not a way around that. The complexity of a given problem is first of all kind of hard to define. But secondly, it's often understated. How many different factors affected that problem in the first place and can you even go back and simulate the problem that occurred? This is for event kind of problems. Or maybe you have a difficult decision to make. How can you possibly understand all of the factors related to that decision? When you look at every problem as it stands in the context of the world, in the context of the universe, then of course it's prohibitively difficult to answer these questions, to come up with good answers of how does that problem interact with the context that it's in. And so we can easily become crippled by our problems. We can easily become crippled by how difficult it is to learn through a problem. And there's not a magic bullet solution here, but I do want to share with you one thing that you can do when you're trying to solve difficult problems. And this is popular advice on the show. We've talked about this in many episodes. In fact, many early episodes, especially. We talked about the idea of making things smaller. When you have a problem that seems impossible to solve, regardless of what domain that problem is in, then the first thing that I recommend that you do is try to reduce the problem to something that you can understand. Something that fits in your head, something that you can reason about, that you can look at for multiple angles and every angle makes sense to you. This means reducing variables. It may mean that you're creating a thought experiment where the problem kind of exists in a vacuum. You remove aspects of that problem that make it complex and you try to simplify it. So what's an example of this? Well, let's say that you are having an error in a script. And you can't quite track down where that error is coming from. You have a bunch of methods, maybe functions, whatever kind of language you're writing in. And all of those functions are calling each other and it seems to be a pretty entangled mess. Once you start tracking it down in one place, it seems to jump around. Almost like the problem is live. And so you start to write debug statements and every debug statement you write seems to confuse you even more. How can you approach solving this problem? Well, one way that you can do this is by taking out everything but the function calls. In other words, take out all the logic and simply leave the function shells, the outer bodies of the functions. And then in the inside of the functions, leave the function calls themselves. So if one function, a, calls function, b, then make sure that stays intact. And what you can see is that the body of the function or the logic, the business logic that actually makes those functions useful, is kind of getting in the way. Sometimes just finding the source, the calling source in your code is really the first problem that you have to solve. Another way that you may simplify this, if you have, for example, a syntax error, is to literally cut out half of your program. I start in the middle and I use a basic dividing conquer algorithm. If I can't figure out what exactly that syntax error is, I'll delete the bottom half of that script, of that function, whatever it is, until I find the half that is causing the issue. Now, if you go and have as a good dividing conquer algorithm would, and it's basically a search algorithm, you eventually narrow things down. And if you try to use just your own logic, rather than this procedure, you may take a lot longer to find that syntax error. There's a hundred other ways that you can apply this to code, but this also applies in other domains like your career. For example, let's say that you have a job offer on the table. And you're trying to decide if you want to leave your secure job for this more risky job. The riskier job pays a little bit more, and if things go really well, the riskier opportunity is actually going to give you a lot more growth in your career. Of course, it also comes with downside that you may fail entirely and lose your job. And so you're trying to decide between these two, these two job options. Now how can you simplify the problem? Or at least how can you simplify the decision so that you understand the key components for you? This is the first step in making good decisions, first of all, but also trying to find third options. This is something else we've talked about on the show before. And the third option is very often we find ourselves in a false dichotomy kind of situation. And this is a perfect example of that, where you have one job or another job. So let's start by eliminating some variables and try to find the ones that really matter to you. And the answer to this is actually different for different people who are listening to this. For example, some people are more tolerant of risk. And so if you eliminate the variable of risk and you know that this other job has more opportunity and more pay, then what's remaining? Well perhaps you have other things that keep you loyal to the job that you have. Maybe there are some other issues that you have with the second opportunity, with the more risky opportunity. Maybe you enjoy the work that you're doing and you don't want to take on any further responsibility. Perhaps if you eliminate the variable of extra pay that your salary would stay the same. Now you're looking at the variable of risk and the other variable of career growth. Is that something that's attractive to you regardless of the pay? Ultimately, what we're trying to do here is find all of these kind of individual components that are composed into this decision. Once you can find these individual components, then you can deal with them rather than dealing with them wholesale, you can try to deal with them individually. So maybe you like the idea of having the career growth, having the extra pay, but you're not really willing to take on the risk. Well how can you mitigate some of that risk? Are there ways that you can have a safe fallback? Maybe you need a safety net of savings? Perhaps the new job opportunity would actually provide that to you, a signing bonus that you can store away so that if you do need to find another job, all of a sudden, if the company tanks overnight, well you can go and do that. So when you break your problems down into their individual components and solve those smaller problems, the ones that you can wrap your head around with a little bit more ease rather than trying to solve the big problem that has multiple complex moving parts that interplay with each other. When you solve the smaller problems, you have a wider variety of options for your solutions. This typically means that you're going to solve with more optimal solutions and it also means that you're going to have more creative control over those solutions. So instead of making wholesale, wide sweeping decisions, you can make more incremental decisions. So, to take away from today's episode is very simple. When you have a complex, difficult problem in front of you, regardless of what domain that's in, whether you're learning to code today or you're trying to make a big career decision, a big personal life decision, reduce the problem. Try to find the smallest version of the problem that you can wrap your head around. Make the problem smaller and then make each problem that composes the bigger one smaller. Make each of those components to the bigger problem. Thank you so much for listening to today's episode. Thank you again to today's sponsor, Century. Go and check out what Century has to offer Century.io. I want to take a moment to thank you for making this podcast possible. Literally, if you go and you leave a review on iTunes or if you subscribe to this podcast, these are all signals that affect our visibility in iTunes. This is the major factor that keeps Developer Teaalive. If other developers can find this show, if they read your review and they decide to listen to it, they also get value out of the podcast and that growth cycle is what allows us to continue doing episodes of Developer Tea. If you haven't left a review in iTunes, but you have found value in this show, then I'd love for you to consider giving back to the show. And the easiest way that you can do that, and it's totally free, just takes a few minutes of your time, is to leave a review on iTunes. Thank you so much for listening to today's episode, and until next time, enjoy your tea.