Make Your Problems Smaller


The. 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 are 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 Cottrell. 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, cinci dot IO century is going to help you find issues in your code. And here's what I love about century instead of taking the normal view that we should always find issues in our code before it gets to production. Cinci 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 is kinds of problems come from a wide variety of reasons. For example, Radic user behavior or just strange environments, that users may have maybe, for example, there's some internet service provider in a state across the country or 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 now. How do you deal with this kind of issue? And how could you ever test for it? Well, it would take a ton of time effort, money resources, whatever you wanna call it. There's a lot of energy going into trying to cover all those cases or you could rely on that production environment to do that for you. And that's what century allows you to do since. Chery catches issues in your production code before, all of your user see them, so you'll get alert 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 century for sponsoring today's episode go, and get started today at century dot IO. Every problem that you solve in your code or in your career and your life. Every problem that your team solves or that country solves is necessarily contextualized with other problems. There are multiple factors to consider. And this 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 in 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 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 he can't quite track down where air is coming from you have a bunch of methods maybe functions. Whatever kind of language you're writing in, in all of those functions are calling each other, and it seems to be pretty entangled mess. Once you start tracking it down in one place, seems to jump around almost like the problem is alive. And so you start to write debugged statements and every debugged statement you, right? 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 wok and simply leave the function shells that outer bodies of the functions. And then in the inside of the functions. Leave the function calls themselves. So one function, a calls function be. Then make sure that stays intact in what you can see is that the body of the function or the logic the business logic that actually makes us functions. Useful 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, syntax air 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 find the half that is causing the issue. Now, if you go in 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 your own logic rather than this procedure, you may take a lot longer to find that syntax air. There's one hundred other ways that you can apply. The code, but this also applies in other domains like your career, for example, but say that you have a job offer on the table, and you're trying to decide if you wanna 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 byu may fail entirely lose your job. And so you're trying to decide between these two these two job options. 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. 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 more pay. Then what's remaining, 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 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 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 him 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, a safe. Net of savings, perhaps, the new job opportunity would actually provide that to you 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 they are going to solve with more optimal solutions. And it also means that you're gonna 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 reduced 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 think you again to today's sponsor century go and check out what century has to offer century, I l I wanna 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 and I tunes, this is the major factor that keeps developer t 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 pie cast, and that growth cycle is what allows us to continue doing episodes of developer t if you haven't left a review nineteen's, 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 you can do that. And it's totally free. Just takes a few minutes of your time. Is to leave a review in ITN's. Thank you so much for listening to today's episode and until next time enjoy your teeth.

Coming up next