Vox

Leitura de 17 min

Problem Solving Series #1: Starting By Making It Worse

Summary

In this episode, Jonathan Cuttrell kicks off a series on problem-solving for developers. He challenges the common instinct to immediately try to fix a problem and instead proposes a counterintuitive strategy: first, try to make the problem worse. This approach helps uncover the true contributing factors and shape of the issue.

Cuttrell uses the example of a slow web server to illustrate the method. Instead of scaling up resources or applying common optimizations, he suggests deliberately scaling down resources, removing gzipping, or adding computational load to see how these changes affect response time. By treating problem-solving as an experimental process with independent and dependent variables, developers can identify which factors have the most significant impact.

The core insight is that by understanding how to exacerbate a problem, you gain clarity on its root causes. This method moves beyond placebo effects and biased evaluations, forcing a more systematic investigation. It’s a form of subtractive thinking applied to debugging and optimization, helping developers ask better “why” questions and avoid wasted effort on ineffective solutions.

Recommendations

Tools

  • Stack Overflow for Teams — A private, team-based version of Stack Overflow for capturing and sharing institutional knowledge and solutions to team-specific problems, preventing them from being lost in chat threads or old documentation.

Topic Timeline

  • 00:00:00 — Introducing the problem-solving series for developers — Jonathan Cuttrell opens the episode by framing software development as fundamentally about problem-solving. He announces a series focused on improving problem-solving strategies, emphasizing that while problems differ, the common element is the solver—the developer. The approach will blend established principles with new ways of examining challenges.
  • 00:03:12 — Sponsor message: Stack Overflow for Teams — The episode is sponsored by Stack Overflow. Cuttrell discusses how developers commonly use Stack Overflow to find solutions to coding problems. He introduces Stack Overflow for Teams as a private, secure platform for teams to capture and share institutional knowledge, preventing solutions from being lost in Slack threads or old documentation. A promo code is provided for a free trial.
  • 00:05:16 — The common but flawed approach to fixing problems — Using the example of a slow web server, Cuttrell describes the typical reaction: trying to make the bad situation better by applying optimizations or scaling resources. He points out that this often leads to incomplete solutions, placebo effects, or misdiagnosis. He compares it to fixing a car’s check engine light by performing unrelated maintenance—the underlying issue remains.
  • 00:08:21 — Proposing the ‘make it worse’ strategy — Cuttrell introduces the core non-intuitive strategy: instead of trying to improve the problematic metric, deliberately try to make it worse. For the slow server, this means scaling down resources, removing compression, or adding computational load. The goal is to perform controlled experiments to see which changes most significantly affect the dependent variable (response time), thereby revealing the problem’s true shape and key contributing factors.
  • 00:10:14 — Framing problem-solving as a controlled experiment — The host elaborates on the experimental methodology. He defines the independent variable (what you change, like server resources), the dependent variable (what you measure, like response time), and the control (the baseline before changes). By changing one variable at a time and measuring its effect, you can identify which factors have the largest impact and discover unexpected contributors, such as server location.
  • 00:12:56 — Conclusion and call to action — Cuttrell reiterates that understanding how to make a problem worse reveals its most salient contributing factors. He thanks the sponsor, Stack Overflow, and encourages listeners to subscribe to the podcast and leave a review on iTunes to help other developers discover the show and improve their problem-solving skills.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2018-05-07T09:00:00Z
  • Duration: 00:14:13

References

Podcast Info

Transcript

[00:00:00] it’s not an easy task to describe what you do as a software developer to a non-technical person

[00:00:11] let’s say somebody who teleported to us from the 1940s if they asked you what you do as a software

[00:00:19] developer how would you explain it a very simple explanation that a lot of developers including

[00:00:25] myself and especially consulting developers we end up resorting to is that we solve problems

[00:00:32] this is kind of a blanket description of what software developers do and really what any kind

[00:00:38] of consultant position does we solve problems so i want to do a couple of episodes on problem

[00:00:45] solving and specifically finding ways of solving problems better we’re going to use some of the

[00:00:51] principles that we’ve discussed in the past in order to inform

[00:00:55] developers and especially consulting developers to a non-technical person

[00:00:55] some of this but we’re also going to use some perhaps newer strategies and ways of looking at

[00:01:01] problems to discover better ways of solving them my name is jonathan cuttrell and you’re listening

[00:01:06] to developer t and my goal in the show is to help driven developers connect to their career purpose

[00:01:10] do better work so they can have a positive influence on the people around them and we do this

[00:01:16] in part by exploring principles exploring the truth that we can uncover in the world around us

[00:01:23] as well as the

[00:01:25] truth that we’ve discovered through experimentation or perhaps an emerging truth from our own

[00:01:31] experiences because here’s the reality problem solving is not a simple task problem solving

[00:01:39] looks different we create this abstract language around problems but ultimately solving problems

[00:01:46] is not a formulaic thing that we can partake in there are some similarities between one problem

[00:01:54] and the next but we’re going to talk about them in a little bit more detail in the next episode

[00:01:55] but perhaps the most similar thing between solving problem a and solving problem b is the

[00:02:01] solver the person the human you the developer and so a lot of our problem solving strategies

[00:02:08] are less about the problem itself and more about you more about the way that you see the problem

[00:02:16] the way that you deconstruct it the way that you go about exploring around the problem and

[00:02:23] finding ways to

[00:02:25] test ideas and refine your experiments so that you can solve the problem. At a core fundamental

[00:02:33] level, problem solving is no different than any other activity. We’re changing something in our

[00:02:39] world. We see some organization of matter or some common pattern, and we want to shift that pattern.

[00:02:49] We want to shift the organization of the matter, and that’s no different than any other change. But

[00:02:53] problem solving is about finding a way to make that change, finding a way to shift the matter,

[00:03:00] to shift the pattern. In this first episode on problem solving, we’ll discuss a somewhat

[00:03:06] non-intuitive way of looking at a problem. Before we do that, I want to take a moment to thank

[00:03:12] today’s sponsor, Stack Overflow. I bet if you were to go and look at your browser history,

[00:03:18] you would see Stack Overflow all over the place. If you’re like a normal developer,

[00:03:23] if you’re like a normal developer, you would see Stack Overflow all over the place.

[00:03:23] If you’re like a normal developer, if you’re like a normal developer, if you’re like a normal developer,

[00:03:23] you have a problem with your code, and we all have problems with our code,

[00:03:27] and you’re trying to solve that problem, one of the most common things that we need to do is

[00:03:31] go and talk to someone else who has had that problem. And very rarely do we have unique

[00:03:36] problems that haven’t been encountered before. And this is something that Stack Overflow has

[00:03:41] taken advantage of for years. Developers go and share their problems, and then they share their

[00:03:47] solutions on Stack Overflow. And you get to benefit from those years of people sharing those solutions.

[00:03:53] That’s why Stack Overflow is such a popular resource. But sometimes we have problems that

[00:03:59] are kind of unique to our company or to our team. And the solutions are usually hidden somewhere

[00:04:06] deep inside of a Slack message thread, or, you know, maybe an email thread, or some kind of

[00:04:13] old documentation, maybe have to dig through a bunch of commits to find a particular comment

[00:04:19] and a piece of code. And then maybe that repository was deleted. All of these solutions are hidden

[00:04:23] somewhere deep inside of a Slack message thread, or, you know, maybe an email thread. All of these

[00:04:23] things happen around solving team specific problems. But now you can solve that in a better

[00:04:30] way. Stack Overflow has just launched Stack Overflow for Teams. It’s basically what you’re

[00:04:35] used to with Stack Overflow. Except now it’s in a private space for you and your team to use. And of

[00:04:41] course, it’s secure as well. So you’re not sharing all of your company secrets to Stack Overflow for

[00:04:48] everyone else to see. If you’ve ever fought to keep your documentation up to date, or if you’ve

[00:04:53] ever had questions about how to use Stack Overflow, you can go to stackoverflow.com. And you can

[00:04:53] question and answer sessions that you wish somebody had been recording, I encourage you to

[00:04:57] go and check out Stack Overflow for Teams, head over to s.tk slash developer T, that’s s.tk slash

[00:05:05] developer T to get started today, your first 14 days are free on Stack Overflow for Teams. Thank

[00:05:11] you again to Stack Overflow for sponsoring today’s episode of developer T. So we’re talking about

[00:05:16] solving problems today. And imagine that you’re having a, an issue where your server,

[00:05:23] is running very slowly. This is a problem that a developer may solve. You’re trying to figure out

[00:05:30] why is it that this server is responding, let’s say it’s a web server, that your web service is

[00:05:35] taking much longer than it normally would. It’s taking maybe three seconds to respond,

[00:05:42] when normally it takes three tenths of a second. Why is that happening? Now the common response to

[00:05:47] this, no pun intended, is to go and try to fix it, try to make the server response faster.

[00:05:52] And so you may go and make sure your resources are g-zipping, and whatever, whatever other tricks

[00:05:59] you may want to try, you may actually slide the slider on your resources, let’s say you’re using

[00:06:04] Heroku or something, you may scale up your resources trying to increase your computing

[00:06:09] power, or maybe increase your available memory, or something like that. And so you’re trying to

[00:06:14] solve this problem by making something that is bad, better. That’s the lever that you’re using.

[00:06:19] And very often we can make strides in this, and we can make strides in this, and we can make strides in

[00:06:22] this particular way. We can decrease that server response time from three seconds back down to two,

[00:06:29] or down to one. But sometimes our solutions are not complete. And in fact, sometimes our solutions

[00:06:36] are ineffective altogether. Sometimes we get intermittent responses to input like this,

[00:06:43] or we’re trying to make something better, and there doesn’t seem to be a huge effect.

[00:06:46] In fact, we can even have a biased response where we’re evaluating the output,

[00:06:52] and we’re saying that it got better, when actually it didn’t. We thought it got better. It’s kind of

[00:06:57] a placebo effect of doing some work, and then looking at the thing and saying, oh yeah, because

[00:07:02] of the work I did, it is indeed better. But the numbers, the data, don’t necessarily support that

[00:07:08] hypothesis. And we’ve all done this. We’ve all spent days trying to make something better,

[00:07:14] putting a lot of energy into, you know, ensuring that we’re doing all of the right things.

[00:07:20] Unfortunately, very often,

[00:07:22] doing all of the right things isn’t really uncovering the bad thing. The kind of source.

[00:07:30] We aren’t really asking those key five whys, you know, asking why over and over,

[00:07:36] to understand why is this thing actually performing poorly.

[00:07:41] This would be kind of like if your car’s engine light comes on, and you take it in for an oil

[00:07:45] change, and get the car washed, and fill up the gas, and maybe even replace the battery and the

[00:07:51] alternator.

[00:07:52] And turn your car back on, and the engine light is still on. Now, the car may be in better

[00:07:58] condition, but the underlying issue that was causing the engine light to be on in the first

[00:08:03] place, well, it’s still there. So what can we do? What can we do that is different from this

[00:08:09] process that is perhaps more enlightening? As with so many other things that we talk about on

[00:08:14] the show, and so many other activities that we take part in, perhaps we should do the opposite.

[00:08:21] In the past, we’ve done a lot of work, and we’ve done a lot of work, and we’ve done a lot of work,

[00:08:22] we’ve talked about creating a not-to-do list, for example. This is not something that’s unique to

[00:08:27] this show. You’ve probably heard it on other podcasts. We’ve also talked about subtractive

[00:08:32] thinking. What should we do in our day versus what shouldn’t we do in our day? What should we

[00:08:38] take part in as a developer? What languages should we not learn? What languages should

[00:08:43] we stop learning? In today’s episode, we’re going to think about the opposite of making

[00:08:48] something better. In fact, we’re going to try to make our problem worse.

[00:08:52] We’re going to go in and try to make this server slow down, and then observe the effect of that

[00:09:00] action. For example, we may scale back our resources to see how much of an effect that

[00:09:06] actually has. Once we start messing with various parameters, trying to make something worse

[00:09:11] may be a little bit more salient. For example, you may find that scaling down your server,

[00:09:19] taking away computing resources, or taking away some of your resources, may be a little bit more

[00:09:22] time-consuming. You may try to make the page that you’re loading from the server compute

[00:09:34] something really intensive. How much longer does it take for that page to respond? Perhaps

[00:09:41] you have gzipped resources, and you try to un-gzip them.

[00:09:46] Of course, each of these things needs to be done one piece at a time, so you can measure the effect.

[00:09:52] If you just go and start making everything bad, well, that’s not really an effective way

[00:09:57] to perform this particular experiment, because the goal is to look at the effect of what you’re

[00:10:02] doing. Look at what is affecting that load time. Look at what is kind of changing that output

[00:10:08] parameter. You know, if you think about problem solving as an experimental process, then what you

[00:10:14] want to do with a good experiment, we’ll do some basic experiment theory here, with a good

[00:10:20] experiment, you have very good results. You’re going to have very good results. You’re going to have

[00:10:22] very tightly controlled variables. One is a variable that you are changing, right? We call

[00:10:28] this the independent variable, right? It’s not dependent on any other thing in the system,

[00:10:33] because you’re controlling it directly. And then you’re looking at the dependent variable,

[00:10:39] the thing that you are actually caring about, the thing that you want to move the needle on.

[00:10:43] And the third element is the control group. In this case, the control group is the things that

[00:10:48] you had before you started messing with the code. The load time,

[00:10:52] that you were achieving before you started changing your independent variables.

[00:10:57] Now, for a given independent variable, you want to change it to a few different values and then

[00:11:00] measure the effect on the dependent variable. As it turns out, there may be a lot of independent

[00:11:06] variables that have an effect on the dependent variable. This would be true in this particular

[00:11:11] case, where you can obviously increase the load time of your server in more than one way.

[00:11:17] But what you’re trying to do is understand the shape of the problem.

[00:11:21] Understand,

[00:11:22] which of these variables that you’re changing has the largest effect?

[00:11:27] Where are the thresholds for those effects? If I change the computing resources by 10%?

[00:11:34] Does it have a 10% effect? Does it have a measurable effect that I can actually rely on?

[00:11:41] Once you’re able to see the shape of the problem, and you can see all of the different things that

[00:11:46] you are changing, clearly correlated or not correlated with the dependent variable, in this

[00:11:52] case, the server response time, now you can start troubleshooting a little bit more clearly.

[00:11:58] You may also find that all of the things that you expected to have an effect are less effective than

[00:12:05] you expected them to be. And you may also uncover things that you didn’t expect to uncover by doing

[00:12:11] this. For example, if you changed a variable like the location of the server, the physical location,

[00:12:18] perhaps this is entirely responsible.

[00:12:21] By approaching the

[00:12:22] problem, not from the perspective of how do I make this better, but rather, how can I increase

[00:12:30] the severity of the existing problem? How can I increase the load time? Now you start kind of

[00:12:38] uncovering the contributing factors. And that’s really the whole goal of this exercise. How can I

[00:12:44] make the problem worse? Once you can understand how you can make the problem worse, perhaps you

[00:12:50] understand the most salient,

[00:12:52] contributing factors to the problem to begin with.

[00:12:56] Thanks so much for listening to today’s episode of Developer Tea. And thank you again to Stack

[00:13:00] Overflow for sponsoring today’s episode. You can get Stack Overflow for your team. That means

[00:13:06] questions that your team is asking other members of your team. It’s kind of like an internal wiki

[00:13:11] on steroids. Go and check it out. s.tk slash developer tea. That’s s.tk slash developer tea.

[00:13:19] Your first 14 days will be free.

[00:13:22] On Stack Overflow for teams. Thank you again for listening. If you’re enjoying these episodes of

[00:13:26] Developer Tea, and if we’ve provided any value to you whatsoever, then I’d love to request just a

[00:13:33] few minutes of your time. In the first minute of your time, go and subscribe in whatever podcasting

[00:13:38] app you are currently using. Now that should only take about 10 seconds. Then you can use the rest

[00:13:42] of that time to go and leave us a review and a rating in iTunes. I read every single one of these

[00:13:47] reviews, and I’ve been refreshing in recent days to read each of them. Thank you so much for listening.

[00:13:52] Thank you so much to those of you who have left a review. This is the best way to help other

[00:13:55] developers just like you find Developer Tea, and in this case, start solving problems better.

[00:14:02] Thank you so much for listening, and until next time, enjoy your tea.

Visão de gráfico