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 softer 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 Cottrell and you're listening to Developer Tea. And my goal on this show is to help you solve your problems. So that you can help your 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, Sentry.io. Sentry is going to help you find issues in your code. And here's what I love about Sentry. Instead of taking the normal view that we should always find issues in our code before it gets to production, Sentry 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. Maybe, for example, there's some internet service provider in a state where they're not able to simulate problems. And they're not able to simulate these kinds of things. At the same time, they may have evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution for you. That's what Sentry allows you to do. Sentry 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 Sentry for sponsoring today's episode. Go and get started today at Sentry.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 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 so we can easily become crippled by how difficult it is to learn through a problem. And so 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 from multiple angles and every angle makes sense to you. This means reducing variables. It may mean that you're creating a new problem. At the same time, you may want to find ways toension the evolution of evolution and evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution 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 alive. 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 could 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 function A, the function B, the function A, the function A, the function A, 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 divide and 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 in halves, as a good divide and conquer algorithm would, and it's basically a search algorithm, you eventually narrow things down. Now if you try to use just your own logic, you're going to end up with a lot of problems. So if you're going to 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 the 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 things that keep you loyal to the job that you have. Maybe there are 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? Or is it something that's not attractive to you? 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 extra pay. You're 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, well, you know, 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 creativity. You're going to have more creative control of those solutions. So instead of making wholesale wide sweeping decisions, you can make more incremental decisions. So the takeaway 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. Look at 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, Sentry. Go and check out what Sentry has to offer, sentry.io. And 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 Tea alive. 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, 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, it just takes a few minutes of your time, is to leave a review in iTunes. Thank you so much for listening to today's episode. And until next time, enjoy your tea.