Vox

Leitura de 15 min

Practical Steps for Reframing Problems

Summary

In this episode of Developer Tea, host Jonathan Cottrell delves into the concept of framing and reframing problems. He explains how the specific words we use to describe a problem create a frame that limits our perception and potential solutions. By consciously choosing different language, we can escape these limitations and discover new approaches.

Cottrell emphasizes that framing is a natural and necessary part of human cognition—we create frames to be productive and avoid being overwhelmed by infinite possibilities. However, these frames often become invisible constraints. The key insight is that by intentionally reframing problems using different vocabulary, changing assumptions about severity or ownership, or altering temporal perspectives (like pre-mortems or post-mortems), we can break free from habitual thinking patterns.

He provides concrete techniques for reframing: describing the same problem with entirely different nouns and verbs, imagining giving advice to someone else with the same problem, questioning whether the problem is truly critical to survival, and changing the magnitude of the desired outcome. These exercises help identify gaps between frames and reveal which perspective might be more productive.

The episode concludes with practical advice: reframing is most valuable for consequential problems or as a learning exercise. For simple problems, reframing might consume more energy than solving the problem directly. Cottrell encourages developers to practice reframing to become more effective problem-solvers and to approach their work with greater clarity and purpose.

Recommendations

Movies

  • The Princess Bride — Referenced as a lighthearted example of what happens when you have too many frames of reference, specifically mentioning the ‘death of Vizzini’ scene.

Tools

  • Educative.io — Sponsored educational platform offering text-based courses with pre-configured developer environments for topics like machine learning, Kubernetes, AWS, and system architecture.

Topic Timeline

  • 00:00:00 — Introduction to framing and how language limits problems — Jonathan Cottrell introduces the episode’s theme: how the words we use to describe problems create frames that limit possible solutions. He explains that by compressing problems into specific language, we inadvertently restrict our thinking and eliminate alternative approaches before we even begin solving.
  • 00:01:37 — How teams create frames through specifications and tasks — Cottrell discusses how engineering and product teams naturally create frames when they translate ambiguous problems into specific tasks (like JIRA cards). While this breakdown into action steps is necessary for productivity, it also creates a fixed perspective that can limit innovation if not examined.
  • 00:03:44 — The necessity and limitations of frames in everyday life — The host explains that framing is biologically and practically necessary—we can’t consider every angle of every problem. However, frames become conglomerations of heuristics that can be limiting. He references a scene from The Princess Bride as a humorous example of having too many frames.
  • 00:05:55 — Practical reframing technique: using different words — Cottrell presents the first practical reframing technique: consciously using different vocabulary to describe the same problem. He advises against simple synonym substitution and instead recommends finding entirely different nouns and verbs to explain the core issue, then examining the gaps between descriptions.
  • 00:07:22 — Reframing assumptions about problem ownership and severity — The host suggests reframing problems by changing assumptions about ownership (imagining giving advice to someone else) and severity (questioning whether survival truly depends on solving it). This mental shift can reveal new perspectives and reduce emotional attachment that might cloud judgment.
  • 00:08:42 — Temporal reframing: pre-mortems and post-mortems — Cottrell introduces temporal reframing techniques: imagining you’ve already succeeded (post-mortem of success) or already failed (pre-mortem). Looking at problems from different points in time helps identify critical steps and potential pitfalls that aren’t visible from the present perspective.
  • 00:09:27 — Changing magnitudes to find problem edges — Using the example of optimizing web server response time, Cottrell demonstrates how changing the magnitude of the goal (cutting by 100ms vs. 500ms vs. aiming for 100ms total) can reveal different solution strategies and help define the true boundaries of the problem.
  • 00:10:54 — When reframing is and isn’t valuable — The host concludes by noting that reframing isn’t always worthwhile—for simple problems, it might take more energy than solving the problem directly. Reframing should be reserved for consequential problems or used intentionally as a learning exercise to develop the skill.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-04-01T09:00:00Z
  • Duration: 00:12:59

References

Podcast Info

Transcript

[00:00:00] what words are you using to describe a problem in today’s episode we’re talking about the concept

[00:00:14] of framing and more importantly reframing to understand your problems more effectively and

[00:00:22] perhaps help you approach your job your life your career from a different frame than usual

[00:00:30] my name is jonathan cattrall you’re listening to developer t my goal on the show is to help

[00:00:34] driven developers like you find clarity perspective and purpose in their careers

[00:00:38] what words do you use to describe your problems this is such an important question because

[00:00:44] most of the time our words limit a problem

[00:00:51] to

[00:00:52] a much smaller frame and when we limit the problem to the smaller frame we necessarily

[00:00:59] are cutting out possible answers to a slightly different frame of the same problem

[00:01:06] let’s think about that for a second when you use words to describe a problem and you

[00:01:12] limit your description of that problem to those specific words

[00:01:16] it’s very likely that you are compressing

[00:01:22] the problem and therefore the possible solutions to the problem in unexpected or perhaps subversive

[00:01:30] ways. So what does this mean in practice? Well, most of the time when we think about a given

[00:01:37] problem, we think about it in a way that it has been presented to us or in a way that we have

[00:01:43] written it down, a way that we’ve talked about it to other people, and language can shape our

[00:01:50] perception of a problem drastically. We know this as engineers, especially if you’ve worked

[00:01:55] on a product team or another similar kind of engineering team where you have a given problem

[00:02:02] that is brought to the table and then the team brainstorms around it and then outputs some kind

[00:02:07] of specification. That specification might be a card in JIRA. And what’s interesting is that

[00:02:15] we’ve framed the problem in terms of tasks.

[00:02:18] After we’ve consumed the problem in more ambiguous terms, part of the job of a product

[00:02:27] team is to understand problems thoroughly and then come up with practical solutions to those

[00:02:32] problems. And so in some ways, it’s necessary to create a specific frame and to break a problem

[00:02:40] down as far as possible into action steps. This is a good pattern to have, and it makes sense

[00:02:48] from kind of an evolutionary standpoint as well, that we would create a quick frame, a useful frame

[00:02:55] as soon as possible, that we don’t try to consider every possible option, that we use various

[00:03:04] heuristics to materialize that frame as well. Some of our frame will be implicit, some of it will be

[00:03:11] explicit. Some of our frame is based on our shared values, the values that we’re executing on inside

[00:03:18] of that frame. Those are kind of the implicit parts of the frame. And so when we create these

[00:03:24] frames, especially when we do it in a collaborative atmosphere, we’re creating the frame in order to

[00:03:31] reduce the number of options, reduce the number of pathways that we might choose to go down.

[00:03:38] Sometimes we do this intentionally, but most of the time we’re creating frames naturally.

[00:03:44] This is a part of our everyday lives. We have to have a frame of

[00:03:48] reference. We have to have a frame of reference. We have to have a frame of reference. We have to

[00:03:48] have a frame of reference. And we’re kind of biologically limited to a literal frame of reference, but

[00:03:54] we also create frames in order to be productive. We can’t spend all of our time imagining every

[00:04:01] problem from every angle. That would be debilitating. If you’d like a lighthearted look

[00:04:07] at what it looks like to have too many frames of reference, there’s a classic scene from the movie

[00:04:14] The Princess Bride, the death of Vizzini. I won’t ruin

[00:04:18] the dialogue, but this is a perfect example of this. So the idea here is that we can create

[00:04:26] these frames and that we must create the frames to be productive, but that the frames can be

[00:04:31] limiting. We’ve talked about how heuristics can be limiting and frames are another kind of

[00:04:36] conglomeration of heuristics. And it’s one of the easiest ways to practically escape your heuristics,

[00:04:44] to create, intentionally create a different frame for your

[00:04:48] project. And that’s one of the easiest ways to practically escape your heuristics, to intentionally create a different frame for your project.

[00:04:48] And we’re going to talk about ways that you might do that with particular types of frames right after we talk about

[00:04:54] today’s brand new sponsor, Educative.io. For developers, the learning never stops. There

[00:05:02] are always new languages, frameworks, and technologies. Educative helps you learn

[00:05:07] faster and more efficiently. Instead of video-based courses, which require you to kind of scrub back

[00:05:12] and forth, their courses are all text-based. So you can skim and double back easily, almost like

[00:05:18] a book. Each course also contains pre-configured developer environments, so you can practice as you

[00:05:24] learn. Courses cover all kinds of in-demand topics like machine learning, Kubernetes, AWS, system

[00:05:30] architecture, and more. They just launched subscriptions at almost 50% off. So this is a

[00:05:36] great time to go check it out. You can get an additional 10% off everything by visiting

[00:05:41] educative.io slash developer T. That’s educative.io slash developer T.

[00:05:48] All one word. Thanks so much to Educative for sponsoring today’s episode of Developer T.

[00:05:55] Framing starts with words. Words that you choose to describe a problem, a situation,

[00:06:01] to describe your perspective even. And so it makes sense that in order to practice reframing,

[00:06:09] we should try using different words for the same concept. And this is exactly what I would like for

[00:06:15] you to try. The next time you come up with a new framework, you’re going to want to try it with

[00:06:18] a particularly interesting or worthwhile problem to reframe. First, try to say it a different way.

[00:06:26] Try to look at the problem with new words. Don’t just do this with thesaurus and

[00:06:33] substitute synonyms. Try to explain the problem with a different vocabulary. Try to use

[00:06:41] different nouns and different verbs entirely to explain the core of the problem.

[00:06:48] problem. And when you see differences between your original explanation and your new explanation or

[00:06:55] your new frame, that’s where you can start to ask questions. Why is there a gap between the first one

[00:07:02] and the second one? And which one is the frame that is more productive or more useful for you?

[00:07:09] So this reframing is directly about language that you’re using to describe a problem. But

[00:07:13] imagine if you could reframe your assumptions as well. So for example, let’s say that you are

[00:07:22] describing a problem that you’re having in your business today. And this problem is critical.

[00:07:29] It’s critical to your success as an organization, maybe critical to survival as a startup.

[00:07:36] One thing you can try in these kinds of scenarios is to reframe that problem as if it was someone

[00:07:43] else.

[00:07:43] Reframe it as if you are giving advice to another person, another organization. What would you tell

[00:07:52] them? And why? Once again, look at the differences between the kind of advice that you’re trying to

[00:07:59] give yourself versus the kind of advice that you would give someone else. Another thing you can do

[00:08:05] to reframe your own assumptions is to imagine that this problem was not critical, that your survival

[00:08:12] didn’t rely on this problem being solved. The same can be said about the opposite direction.

[00:08:20] And in fact, it’s probably a little bit easier to look at it from the opposite direction,

[00:08:24] where your survival does not necessarily depend on this particular problem, but imagining

[00:08:32] that it does might clarify a way forward. You can even try to imagine reframing as if you had

[00:08:42] already solved the problem. This idea is commonly called a post-mortem. In this case,

[00:08:50] it’s a post-mortem in the successful direction. So you’re looking back and you’re realizing that

[00:08:56] you had succeeded. Well, what were the critical steps? What critical things had to occur for that

[00:09:01] to happen? Of course, you’ve probably also heard about the pre-mortem, which is holding a post-mortem

[00:09:09] just in advance, right?

[00:09:11] So you’re imagining that you have failed already at this problem. You’re looking from a different

[00:09:17] temporal frame at the same issue. You can also manipulate the severity or the particulars,

[00:09:27] the magnitudes in your problem. So imagine that you are trying to increase the speed of your

[00:09:35] application. And so you’re trying to reduce the response time, let’s say, on your web server

[00:09:41] and control the speed of your application. And so you’re trying to reduce the response time,

[00:09:41] cut it in half. It’s taking a second to load. You want it to take 500 milliseconds. Well,

[00:09:47] what happens if you try to only cut it by, let’s say, 100 milliseconds? What kind of strategy might

[00:09:53] you use to solve that problem? Or on the opposite end of that kind of magnitude change, what if you

[00:10:00] were trying to get it to load in 100 milliseconds? This is much more of a drastic cut in that load

[00:10:08] time.

[00:10:11] And so you’re trying to reduce the speed of your application. You want it to take 500 milliseconds.

[00:10:12] Changing the magnitudes might help you find the edges of your problem a little bit better.

[00:10:19] These examples are why framing is so important. When we choose a specific frame, it gives us

[00:10:27] better boundaries for what we’re trying to accomplish. And sometimes when we choose a frame,

[00:10:34] we choose the wrong frame. Or we could choose a slightly different frame and achieve most

[00:10:41] of the value or even greater value than our initial frame with the same amount of energy.

[00:10:47] One final note about framing. It’s not always valuable to consider another frame. Sometimes

[00:10:54] our problems are very simple and reframing them takes just as much energy as solving the problem

[00:11:01] in the first place. And so it makes sense to reserve reframing for either consequential

[00:11:06] problems or for the sake of learning. If you’re using reframing on anything,

[00:11:11] an inconsequential problem, then do so with the intent of learning how reframing works.

[00:11:18] Thanks so much for listening to today’s episode of Developer Tea. Thank you again to today’s

[00:11:22] sponsor, Educative. You can supercharge your career with interactive text-based software

[00:11:28] courses by visiting educative.io slash developer tea. That’s going to get you an additional 10%

[00:11:35] off. They’re already doing 50% off on their subscriptions, nearly 50% off. You’re going to

[00:11:40] get an additional 10% off on their subscriptions, nearly 50% off. You’re going to get an additional

[00:11:41] 10% off just for being a listener of this show. That’s educative.io slash developer tea.

[00:11:47] Before we close out the episode, I want to ask you a very simple question.

[00:11:51] What kind of developer listens to this show? What kind of developer listens to Developer Tea?

[00:12:00] My hope is that the people who listen to the show are committed. They’re committed to

[00:12:06] becoming better developers. They’re committed to making their teams better.

[00:12:11] They’re committed to building positive relationships with other developers and

[00:12:16] supporting each other. They’re committed to high levels of conscience and making their communities

[00:12:22] better. If you are that kind of developer, you are who this show is made for. I’d love to hear

[00:12:31] from you. You can email me at developertea at gmail.com. And if you do believe that you’re a

[00:12:37] part of that group, then I encourage you to subscribe and whatever podcasting,

[00:12:41] app you’re currently using. Thanks so much for listening to today’s episode.

[00:12:45] This episode was produced by Sarah Jackson. My name is Jonathan Cottrell.

[00:12:50] And until next time, enjoy your tea.

Visão de gráfico