Vox

Leitura de 15 min

Make Your Problems Smaller

Summary

The episode explores the common challenge of facing complex, multi-faceted problems in software development, career choices, and personal life. Host Jonathan Cottrell argues that these problems are rarely singular but are composed of many interrelated issues, which can feel overwhelming and paralyzing.

He introduces a core strategy: making problems smaller. This involves reducing a large, seemingly intractable problem into a version you can fully understand and reason about. In a coding context, this might mean stripping away business logic to isolate function call chains or using a divide-and-conquer approach to find a syntax error by systematically eliminating halves of the code.

The principle extends beyond technical work. When facing a difficult career decision, such as choosing between a secure job and a riskier opportunity, the advice is to break the decision down into its component variables—like risk tolerance, desire for growth, and compensation—and address each one individually. This process can reveal third options or mitigation strategies, such as building a financial safety net, that weren’t apparent when looking at the problem as a monolithic whole.

By solving these smaller, constituent problems, you gain more creative control and often arrive at more optimal solutions than if you tried to tackle the entire complex issue at once. The overarching takeaway is a simple, repeatable tactic: when stuck, intentionally reduce the scope and complexity of the problem to something you can wrap your head around, thereby making it solvable.

Recommendations

Tools

  • Sentry.io — A tool for error monitoring that catches issues in production code, allowing developers to find and fix problems triggered by real user behavior and environments that are hard to simulate in testing.

Topic Timeline

  • 00:00:00 — Introduction to Complex, Multi-faceted Problems — Jonathan Cottrell introduces the episode’s theme: the problems we face in code, relationships, and careers are rarely single issues but are composed of many interrelated factors. This complexity can be paralyzing, and the episode will offer a way to make problems easier to solve.
  • 00:01:05 — Sponsor Segment: Sentry.io — A sponsorship message for Sentry.io, a tool for catching errors in production code. The host highlights its value in finding issues that are impossible to simulate in testing environments, such as those caused by erratic user behavior or unique environmental factors, allowing teams to fix problems before they affect many users.
  • 00:04:30 — The Core Strategy: Make Problems Smaller — The host presents the central advice: when faced with an impossible-seeming problem, reduce it to a version you can understand. This involves stripping away variables, creating thought experiments, or simplifying the context so you can reason about it from all angles. The goal is to get the problem to a size that fits in your head.
  • 00:05:35 — Coding Example: Debugging Entangled Functions — A practical example in software development: debugging a complex script where an error seems to jump around. The suggested simplification is to remove all business logic and leave only the shell of functions and their call chains to isolate the source. Another example is using a divide-and-conquer search algorithm to find a syntax error by deleting halves of the code.
  • 00:07:55 — Career Example: Deciding Between Job Offers — Applying the ‘make it smaller’ principle to a career decision, like choosing between a secure job and a riskier, higher-growth opportunity. The advice is to break the decision into component variables (risk, pay, growth, job satisfaction) and evaluate them individually. This process helps avoid false dichotomies and can reveal third options or risk-mitigation strategies.
  • 00:11:18 — Benefits of Solving Smaller Component Problems — Summarizing the advantages of the approach. By solving the smaller problems that compose a larger one, you have more options and creative control, leading to more optimal and incremental solutions. This is contrasted with trying to solve a complex problem with many interacting parts all at once.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2019-05-22T09:00:00Z
  • Duration: 00:13:38

References

Podcast Info

Transcript

[00:00:00] Often the problems that we are trying to solve are not actually singular problems.

[00:00:09] This is true both in our code and in our relationships, our kind of softer problems,

[00:00:17] career kinds of problems. Typically when we face some kind of adversity, whether that is some kind

[00:00:25] of technical adversity or some kind of cultural adversity, it’s not so simple. There’s not a

[00:00:33] single issue that we’re trying to solve but rather a host of issues, a handful of them.

[00:00:38] In today’s episode we’re going to look at a way to make your problems easier or at least try

[00:00:48] solving them in an easier way. My name is Jonathan Cottrell and you’re listening to

[00:00:52] Developer Tea and my goal on this show is to help

[00:00:55] you solve your problems.

[00:00:55] Today’s episode is a little bit shorter than our average episode so we’re going to go ahead

[00:01:05] and talk about today’s awesome sponsor Sentry.io. Sentry is going to help you find

[00:01:12] issues in your code and here’s what I love about Sentry. Instead of taking the normal view that

[00:01:20] we should always find issues in our code before it gets to production,

[00:01:25] Sentry approaches things from a higher leverage position. When you have real users using your

[00:01:32] application, you’re much more likely to find problems that you couldn’t simulate in the first

[00:01:38] place. These kinds of problems come from a wide variety of reasons. For example, erratic user

[00:01:45] behavior or just strange environments that users may have. Maybe, for example, there’s some internet

[00:01:52] service provider in a state across the country that has a lot of problems. For example, there’s a

[00:01:55] country across the world that’s blocking some of your assets and there’s no way for you to know

[00:02:02] until you get into production. Now, how do you deal with this kind of issue and how could you

[00:02:08] ever test for it? Well, it would take a ton of time, effort, money, resources, whatever you want

[00:02:14] to call it. There’s a lot of energy going into trying to cover all of those cases. Or you could

[00:02:22] rely on that production environment to do that for you. So, if you’re in a situation where you’re

[00:02:25] that’s what Sentry allows you to do. Sentry catches issues in your production code before all of your

[00:02:34] users see them. So, you’ll get alerts and you can deal with the issue immediately rather than three

[00:02:41] months down the road when a bunch of your users have already left. Thanks so much to Sentry for

[00:02:47] sponsoring today’s episode. Go and get started today at Sentry.io. Every problem that you solve,

[00:02:55] In your code, or in your career, in your life, every problem that your team solves, or that

[00:03:02] a country solves, is necessarily contextualized with other problems.

[00:03:10] There are multiple factors to consider, and there’s really not a way around that.

[00:03:17] The complexity of a given problem is, first of all, kind of hard to define.

[00:03:23] But secondly, it’s often understated.

[00:03:27] How many different factors affected that problem in the first place, and can you even go back

[00:03:33] and simulate the problem that occurred?

[00:03:37] This is for event kind of problems, or maybe you have a difficult decision to make.

[00:03:42] How can you possibly understand all of the factors related to that decision?

[00:03:46] When you look at every problem as it stands, in the context,

[00:03:53] in the context of the world, in the context of the universe, then of course it’s prohibitively

[00:03:59] difficult to answer these questions, to come up with good answers of how does that problem

[00:04:07] interact with the context that it’s in.

[00:04:12] And so we can easily become crippled by our problems.

[00:04:15] We can easily become crippled by how difficult it is to learn through a problem, and there’s

[00:04:21] not a magic bullet solution.

[00:04:22] But I do want to share with you one thing that you can do when you’re trying to solve

[00:04:30] difficult problems.

[00:04:33] And this is popular advice on the show.

[00:04:35] We’ve talked about this in many episodes.

[00:04:38] In fact, many early episodes, especially, we talked about the idea of making things

[00:04:44] smaller.

[00:04:46] When you have a problem that seems impossible to solve, regardless of what domain that

[00:04:52] problem is in, then the first thing that I recommend that you do is try to reduce the

[00:04:59] problem to something that you can understand.

[00:05:04] Something that fits in your head, something that you can reason about, that you can look

[00:05:08] at from multiple angles, and every angle makes sense to you.

[00:05:15] This means reducing variables.

[00:05:17] It may mean that you’re creating a thought experiment where the problem kind of again,

[00:05:22] exists in a vacuum.

[00:05:25] You remove aspects of that problem that make it complex, and you try to simplify it.

[00:05:34] So what’s an example of this?

[00:05:35] Well, let’s say that you are having an error in a script, and you can’t quite track down

[00:05:41] where that error is coming from.

[00:05:44] You have a bunch of methods, maybe functions, whatever kind of language you’re writing in,

[00:05:49] and all of those functions are calling each other.

[00:05:51] And it seems to be.

[00:05:52] A pretty entangled mess.

[00:05:55] Once you start tracking it down in one place, it seems to jump around, almost like the problem

[00:06:00] is alive.

[00:06:02] And so you start to write debug statements, and every debug statement you write seems

[00:06:08] to confuse you even more.

[00:06:11] How can you approach solving this problem?

[00:06:14] Well, one way that you could do this is by taking out everything but the function calls.

[00:06:21] In other words, take out all the logic and simply leave the function shells, which are

[00:06:29] the outer bodies of the functions.

[00:06:31] And then in the inside of the functions leave the function calls themselves.

[00:06:37] So if one function A calls function B, then make sure that stays intact.

[00:06:43] And what you can see is that the body of the function or the logic, the business logic

[00:06:48] that actually makes those functions useful, is kind of getting in the way.

[00:06:49] Doesn’t make your old memory and erase function, where you can hate function if you don’t

[00:06:50] want to�

[00:06:50] well…

[00:06:50] if you don’t want your old memory getting set up.

[00:06:50] Never use that tool, but it’s okay for you to play with the booklet.

[00:06:51] You’re not gonna finish all of it.

[00:06:51] the way. Sometimes just finding the source, the calling source in your code is really the first

[00:07:01] problem that you have to solve. Another way that you may simplify this if you have, for example,

[00:07:06] a syntax error is to literally cut out half of your program. I start in the middle and I use

[00:07:14] a basic divide and conquer algorithm. If I can’t figure out what exactly that syntax error is,

[00:07:20] I’ll delete the bottom half of that script, of that function, whatever it is, until I find the

[00:07:27] half that is causing the issue. Now if you go in halves as a good divide and conquer algorithm would

[00:07:35] and it’s basically a search algorithm, you eventually narrow things down. Now if you try

[00:07:42] to use just your own logic rather than this procedure, you may take a lot longer to find

[00:07:48] that syntax error.

[00:07:50] There’s a hundred other ways that you can apply this to code, but this also applies in other

[00:07:55] domains like your career. For example, let’s say that you have a job offer on the table and you’re

[00:08:03] trying to decide if you want to leave your secure job for this more risky job. The riskier job pays

[00:08:10] a little bit more and if things go really well, the riskier opportunity is actually going to give

[00:08:17] you a lot more growth in your career.

[00:08:20] Of course, it also comes with the downside that you may fail entirely and lose your job.

[00:08:27] And so you’re trying to decide between these two, these two job options.

[00:08:33] Now how can you simplify the problem? Or at least how can you simplify the decision

[00:08:39] so that you understand the key components for you? This is the first step in making good decisions,

[00:08:48] first of all, but also,

[00:08:50] trying to find third options. This is something else we’ve talked about on the show before.

[00:08:55] And the third option is very often we find ourselves in a false dichotomy kind of situation.

[00:09:01] And this is a perfect example of that, where you have one job or another job. So let’s start by

[00:09:08] eliminating some variables and try to find the ones that really matter to you. And the answer

[00:09:15] to this is actually different for different people who are listening to this. For example,

[00:09:20] some people are more tolerant of risk. And so if you eliminate the variable of risk, and you know

[00:09:30] that this other job has more opportunity and more pay, then what’s remaining? Well perhaps you have

[00:09:37] other things that keep you loyal to the job that you have. Maybe there are some other issues that

[00:09:44] you have with the second opportunity, with a more risky opportunity. Maybe you enjoy the work that

[00:09:50] doing and you don’t want to take on any further responsibility. Perhaps if you

[00:09:56] eliminate the variable of extra pay that your salary would stay the same. Now

[00:10:04] you’re looking at the variable of risk and the other variable of career growth.

[00:10:10] Is that something that’s attractive to you regardless of the pay? Ultimately

[00:10:16] what we’re trying to do here is find all of these kind of individual components

[00:10:21] that are composed into this decision. Once you can find these individual

[00:10:27] components then you can deal with them rather than dealing with them wholesale.

[00:10:32] You can try to deal with them individually. Maybe you like the idea

[00:10:37] of having the career growth having the extra pay but you’re not really willing

[00:10:43] to take on the risk.

[00:10:45] How can you make that decision?

[00:10:46] Well how can you make that decision?

[00:10:46] you mitigate some of that risk? Are there ways that you can have a safe fallback? Maybe you need

[00:10:52] a safety net of savings. Perhaps the new job opportunity would actually provide that to you,

[00:10:59] a signing bonus that you can store away so that if you do need to find another job,

[00:11:05] all of a sudden, if the company tanks overnight, well, you can go and do that.

[00:11:10] So, when you break your problems down into their individual components and solve those smaller

[00:11:18] problems, the ones that you can wrap your head around with a little bit more ease, rather than

[00:11:24] trying to solve the big problem that has multiple complex moving parts that interplay with each

[00:11:30] other, when you solve the smaller problems, you have a wider variety of options for your solutions.

[00:11:36] This typically means that you’re going to solve with more

[00:11:40] options than you’re going to solve with more options.

[00:11:40] Optimal solutions. And it also means that you’re going to have more creative control of those

[00:11:44] solutions. So, instead of making wholesale wide sweeping decisions, you can make more incremental

[00:11:51] decisions. So, the takeaway from today’s episode is very simple. When you have a complex, difficult

[00:11:58] problem in front of you, regardless of what domain that’s in, whether you’re learning to code today,

[00:12:04] or you’re trying to make a big career decision, a big personal life decision, reduce the problem.

[00:12:09] Try to find the smallest version of the problem that you can wrap your head around. Make the problem

[00:12:15] smaller. And then make each problem that composes the bigger one smaller. Look at each of those

[00:12:22] components to the bigger problem. Thank you so much for listening to today’s episode. Thank you

[00:12:29] again to today’s sponsor, Sentry. Go and check out what Sentry has to offer, sentry.io. And I want to

[00:12:35] take a moment to thank you for making this podcast possible. Literally,

[00:12:39] if you go and you leave a review on iTunes, or if you subscribe to this podcast,

[00:12:47] these are all signals that affect our visibility in iTunes. This is the major factor that keeps

[00:12:54] Developer Tea alive. If other developers can find this show, if they read your review and they decide

[00:13:01] to listen to it, they also get value out of the podcast. And that growth cycle is what allows us

[00:13:07] to continue doing episodes of Developer Tea.

[00:13:09] If you haven’t left a review on iTunes, but you have found value in this show,

[00:13:15] then I’d love for you to consider giving back to the show. And the easiest way that you can do that,

[00:13:22] and it’s totally free, it just takes a few minutes of your time, is to leave a review on iTunes.

[00:13:27] Thank you so much for listening to today’s episode. And until next time, enjoy your tea.

Visão de gráfico