Vox

Leitura de 19 min

Problem Solving Series #3: Perspective Shifts

Summary

In this third episode of the Problem Solving Series on Developer Tea, host Jonathan Cuttrell addresses the common experience of being stuck on a problem—whether in code, interpersonal relationships, or business—and feeling unable to make progress. He compares this to being unable to see the forest for the trees, where our deep immersion in a problem and our existing biases prevent us from finding new solutions.

Cuttrell introduces three practical tactics for shifting perspective to overcome these blocks. The first is to “move the problem” by imagining it belongs to someone else, such as a friend or a consulting client. This helps break biases like sunk cost fallacy, allowing you to evaluate the problem more objectively, similar to conducting a premortem analysis.

The second tactic is to explain the problem to someone with no knowledge of the domain. This forces you to return to foundational assumptions and basics, potentially uncovering blind spots. Cuttrell relates this to “duck debugging” in programming and notes how mediation works in interpersonal conflicts by removing historical baggage.

The third tactic is to visualize the problem in a new way, such as changing data structures (e.g., from an array to a heap) or using physical tools like whiteboards or Post-it notes. Cuttrell emphasizes the power of metaphors in computer science (like “trees”) to map virtual concepts to tangible experiences, making problems easier to conceptualize and solve from different angles.

Throughout the episode, Cuttrell ties these tactics back to the core goal of helping developers connect with their career purpose and improve their work. He encourages listeners to leverage these perspective-shifting techniques to break free from problem-solving ruts and approach challenges with renewed clarity.

Recommendations

Concepts

  • Metaphors in Computer Science — The use of metaphors like “trees” to map virtual programming concepts to tangible, physical experiences, helping developers visualize and understand complex problems.

Practices

  • Premortem — A practice where you imagine what failure would look like before it happens, helping to identify weaknesses in a plan and shift perspective from an insider to an observer.
  • Duck Debugging — A debugging technique where you explain your code line by line to someone (or even a rubber duck) to uncover errors or assumptions you might have overlooked.

Tools

  • Linode — A cloud hosting provider promoted as an affordable option for developers, with a 20 credit is offered with the code “developertea2018”.

Topic Timeline

  • 00:00:00 — Introduction to perspective shifts using dimensional analogy — Jonathan Cuttrell opens by using the analogy of trying to understand a fourth dimension to illustrate how difficult it can be to gain a new perspective on a problem. He explains that while we experience three spatial dimensions, imagining a fourth is challenging, similar to how we get stuck in our current viewpoint when problem-solving. This sets the stage for discussing tactics to shift perspective and overcome mental blocks.
  • 00:03:28 — Sponsor message from Linode — The host transitions to a sponsor segment for Linode, a cloud hosting provider. He highlights their affordable 20 credit is promoted using the code “developertea2018” at spec.fm/linode.
  • 00:05:45 — First tactic: Move the problem — Cuttrell introduces the first perspective-shifting tactic: imagine the problem belongs to someone else, like a friend or a consulting client. This helps break biases such as sunk cost fallacy, where you’re overly invested in a particular solution path. By adopting an outsider’s view, you can evaluate the problem more objectively, similar to conducting a premortem analysis to identify potential failures.
  • 00:08:06 — Second tactic: Explain to someone outside the domain — The second tactic involves explaining the problem to someone with no knowledge of the domain, such as a non-developer for a coding issue. This forces you to return to foundational assumptions and basics, potentially uncovering blind spots. Cuttrell relates this to “duck debugging” in programming and notes how mediation works in interpersonal conflicts by removing historical context and focusing on the present situation.
  • 00:11:05 — Third tactic: Visualize the problem in a new way — The third tactic is to visualize the problem differently, such as changing data structures (e.g., from an array to a heap) or using physical tools like whiteboards or Post-it notes. Cuttrell emphasizes the power of metaphors in computer science (e.g., “trees”) to map virtual concepts to tangible experiences. Making the problem more visual or physical can reveal new angles and solutions that weren’t apparent before.
  • 00:14:48 — Conclusion and call to action — Cuttrell wraps up the episode, encouraging listeners to check out previous episodes in the Problem Solving Series and subscribe to the podcast. He asks for reviews on iTunes to help other developers find the show and reiterates the Linode sponsor offer. The episode closes with a reminder of the show’s mission to help developers connect with their career purpose and do better work.

Episode Info

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

References

Podcast Info

Transcript

[00:00:00] have you ever tried to understand what a fourth dimension would be like

[00:00:09] this seems almost impossible of course we don’t experience four dimensions we experience three

[00:00:16] dimensions at least spatial dimensions and it would be very hard to explain what a fourth

[00:00:21] dimension would be like and specifically how it would feel and so perhaps the best way to

[00:00:29] understand how a fourth dimension would feel is instead to imagine that you are living in a

[00:00:35] two-dimensional world and then you have a third dimension added even though it sounds like we’re

[00:00:43] going to be talking about dimensions and physics in today’s episode we’re not talking about that

[00:00:48] at all in fact we’re still talking about problem solving this is the third episode in our problem

[00:00:54] solving series here on developer team my name is jonathan cuttrell and my goal on the show

[00:00:58] is to help

[00:00:59] you

[00:00:59] developers connect to their career purpose and do better work so they can have a positive

[00:01:04] influence on the people around them and although it’s a fun discussion to have about dimensions

[00:01:09] and how you can imagine a world in two dimensions rather than three and then the kinds of things

[00:01:16] you may do to simulate adding that third dimension that’s not what we’re talking about

[00:01:21] really what we’re talking about here is trying to gain a new perspective and why it is that it’s

[00:01:29] so hard to do that you can probably recall multiple problems that you’ve tried to

[00:01:35] solve whether they are in code or if it’s a interpersonal problem or a business problem

[00:01:42] maybe a marketing issue something like this that you are trying to solve and you’re deep in the

[00:01:48] problem and you seem basically stalled you can’t move forward it’s the equivalent of writer’s block

[00:01:56] but for problem solving and the literature involves that causing我们很难以作为一個 Lauria的文化 상 größ的问题而 you seem basically stalled you can’t move forward it’s the equivalent of writers block but for problem-solving and the

[00:01:59] seems to be no way out. But you know theoretically that pretty much any problem that you’re going to

[00:02:04] have interpersonally or in business has some kind of solution. There is some way forward.

[00:02:12] And so you continue grinding away. You continue looking at the problem and you continue being

[00:02:19] stuck. In many ways, this is similar to brute force learning or trying to memorize something

[00:02:25] through repetition. You keep on trying to add this thing to your brain or you keep on trying

[00:02:30] to take a step forward on this problem and you may have very small incremental progress but it seems

[00:02:37] like the rate of progress is slowing to a complete halt. And sometimes it even seems like you’re

[00:02:44] going backwards. Like you’re making the problem worse than it was just a few minutes ago. And what

[00:02:49] causes us to do this? There’s no perfect answer to this question but we’ve all experienced

[00:02:55] this feeling of, you know, not seeing the forest for the trees. We’re in the problem and we’re so

[00:03:02] deeply kind of influenced already that we can’t approach it from a new perspective. We’re kind of

[00:03:10] already poisoned with the knowledge that we have. So how can we break out of this? That’s what we’re

[00:03:17] talking about in today’s episode. And I’m going to share a few tactics that you can use to kind

[00:03:22] of zoom out and hopefully shift your perspective a little bit. Right after we talk about today’s

[00:03:28] awesome sponsor, Linode, I want you to think about something that you pay a dollar a day for.

[00:03:35] Something that’s $30 a month. And then I want you to think about something that you pay 50 cents

[00:03:41] a day for. Be something like 15 bucks a month. Now I want you to try to figure out if you pay

[00:03:49] 20 cents for anything per month.

[00:03:53] The answer is probably not. And in fact, Linode will cost you even less than that.

[00:04:00] You can get started with Linode for only $5 a month. That’s 17 cents a day. It’s actually a

[00:04:07] little bit less than 17 cents a day. This is such a no-brainer investment, especially for new

[00:04:13] developers on this $5 a month plan. And if that’s not affordable enough, Linode is going to give you

[00:04:20] 10 a month. So if you’re going to pay $20 a month,

[00:04:22] it’s equivalent to four months worth of service on this 5 a month

[00:04:29] plan, you get a gigabyte of RAM. You get access to the 40 gigabit internal network. The storage

[00:04:36] for your server is entirely built on SSDs. And customer service at Linode is 24-7. There’s so

[00:04:44] many other options that Linode provides. And it’s not just this introductory plan that Linode has.

[00:04:51] They have support.

[00:04:52] For the largest application that you can imagine building, Linode can support it. They have high

[00:04:58] memory plans. They have extra tools for developers because they are developers. So they understand

[00:05:04] things like locking yourself out of your server accidentally by screwing up a config file. You may

[00:05:11] have gone to your server backup and restored your entire server. But with Linode, you wouldn’t have

[00:05:18] to do that. You can just use the special tool that they have. And to allow you to do that, you can

[00:05:22] back into your server without that config file being correct. There’s a lot of other things that

[00:05:28] Linode offers that we can’t get to in today’s episode. But I encourage you to go and check it

[00:05:32] out. spec.fm slash Linode. And you can get started today. Remember $20 worth of credit for using the

[00:05:38] code developer T 2018. That’s all one word. spec.fm slash Linode. Thank you again to Linode for

[00:05:45] sponsoring today’s episode. So when you’re trying to change perspective, in order to solve a problem,

[00:05:52] there’s a few different tactics that you can use. I’m going to share a couple of them with you today.

[00:05:57] The first tactic is to move the problem. What does this mean? Well, imagine that the problem is not

[00:06:04] yours. Imagine that it’s someone else’s problem. And you are coming in as the benevolent friend

[00:06:11] that you are. And or maybe you’re coming in as a hired consultant and you’re giving them advice

[00:06:17] on how to solve that problem. Suddenly, the way that you see the problem,

[00:06:22] it starts to break some of the bias that you have around the problem. Or at least it’s going to

[00:06:29] highlight some of those biases. So where you previously were perhaps affected by sunk cost,

[00:06:37] right, where you feel like you’ve put a lot of time into this one particular path,

[00:06:41] and you really want to find the solution in that path. If you’re a consultant,

[00:06:46] you wouldn’t really care how much time has been put into a particular path. All you really care

[00:06:52] the problem is solved. And so you may be able to break away from some of those biases that affect

[00:06:58] your ability to decouple yourself from some sunk cost investment. So move the problem.

[00:07:07] This is essentially what you do if you engage in the practice called premortem,

[00:07:12] where you try to imagine what failure would look like before it happens. So you’re trying to

[00:07:21] identify the likelihood of failure. And you’re trying to identify the likelihood of failure. And

[00:07:22] you’re trying to identify the likelihood of failure. And you’re trying to identify the likelihood

[00:07:23] weaknesses in a plan, right? This is a very similar practice, because it changes the

[00:07:29] perspective, the positioning of your perspective, away from a kind of arduous work oriented,

[00:07:38] I’m the problem solver kind of perspective, and towards a more observational perspective,

[00:07:45] someone from the outside looking in. So move the problem. If only in your imagination,

[00:07:52] move the problem.

[00:07:52] So that you can approach it as an outsider, rather than someone who has kind of been toiling away at

[00:08:00] trying to solve the problem. Another tactic, and this one is probably something that you could see

[00:08:06] coming. Explain the problem to someone who has no knowledge of the domain of the problem. So if

[00:08:13] you’re a web developer, explain the problem to someone who isn’t involved in web development

[00:08:19] at all. If you are,

[00:08:22] trying to solve an interpersonal problem, this may be a little bit more difficult, but

[00:08:26] explain the problem to someone who doesn’t know the people that are involved. When you start to

[00:08:32] explain the problem, you’re having to communicate some more foundational things that you otherwise

[00:08:38] may have taken for granted, that aren’t necessarily in in the front of your mind when you’re evaluating

[00:08:45] the problem, but may be important to your problem evaluation process. This is one of the reasons that

[00:08:52] mediation often helps significantly when you have two people who have conflict. Because a mediator

[00:09:01] may have no knowledge of the previous history. They haven’t kept a score. They don’t know if

[00:09:08] one person is more often acting in a particular way, or if the other person more often acts in

[00:09:15] their particular way. They only know what you’re telling them. And so for a given situation,

[00:09:21] mediation,

[00:09:22] process, it may really help. And this is true in other types of problems as well, not just

[00:09:30] interpersonal conflict, but very generally speaking, in almost any kind of problem solving

[00:09:35] context. If you kind of return to a foundational point, return to the basics of the problem you’re

[00:09:44] trying to solve, and reiterate from the basics, kind of a foundational approach,

[00:09:52] build the problem from that foundation. This is also kind of related to duck debugging, right? Where

[00:09:59] you walk through your code one line at a time and explain what each line does. Very often our blind

[00:10:05] spots come from assuming that the line that isn’t producing an error, for example, can be glossed

[00:10:14] over. But when we intentionally refocus our brains on explaining every single line, on returning to

[00:10:22] that foundational aspect, the kind of core, right? When we try to explain our problems to someone

[00:10:30] who is totally unaware of the domain, we may rediscover some relevant aspects of the pieces,

[00:10:39] the parts of the problem that could be exacerbating the problem without us even realizing it.

[00:10:46] And those blind spots that we have, we may be taking a spotlight and shining it directly,

[00:10:52] on one of those blind spots. All right, so that’s tactic number two, explain the problem to

[00:10:59] someone who has no knowledge of the domain of the problem. And finally, tactic number three,

[00:11:05] visualize the pieces and parts of the problem in a new way. Visualize the pieces and parts of the

[00:11:12] problem in a new way. So if you’re working on a problem that is centered on, for example, a

[00:11:18] particular data structure, like an array, then change the way you’re working on the problem.

[00:11:22] Change the data structure. Imagine how the problem will be solved with a different data

[00:11:27] structure. For example, you could shift from an array to a heap. Now, it’s not necessarily the

[00:11:34] case that you’re going to stick with a different data structure, right? You’re not going to use

[00:11:40] this visualization necessarily in the long run, but rather you’re trying to explore the problem

[00:11:46] from different angles. Now, the more visual you can make this, the better. So if you can draw out

[00:11:52] trying to explain on a whiteboard, or if you can model it, for example, using different colored

[00:11:59] post-it notes, right? There are a lot of ways that you can visualize your problems, and suddenly

[00:12:06] something that wasn’t apparent before becomes apparent now. Now, you can do this in a lot of

[00:12:13] different ways. Again, of course, making something visual, you can use different modeling techniques

[00:12:18] to do this, but you can also model your problems through the lens.

[00:12:22] Now, we’ve talked about metaphors and the power of metaphors in the past on this show. I encourage

[00:12:29] you to go back and listen to that episode, and also look at other examples of metaphors in

[00:12:36] computer science history. They’re all over the place in computer science because so many of the

[00:12:41] problems that we solve as developers, really they are virtualized, right? So we’re writing code,

[00:12:48] and we’re having to construct in our minds,

[00:12:52] or in some physical tool like paper and pen, we’re having to construct what the meaning

[00:13:00] of these various problems is. And it can be especially hard when you are brand new to a

[00:13:08] problem, or perhaps the naming structures in the project you’re working on are suboptimal,

[00:13:14] and you’re trying to wrap your brain around what’s happening. What is causing this problem?

[00:13:19] What are the pieces of this problem? How should this thing behave?

[00:13:23] If I looked at it differently, what would it look like? If I flipped the problem on its side,

[00:13:30] what would it look like? And the more physical that you can get with this,

[00:13:34] the more visual you can get with it, the more likely you are to effectively change your

[00:13:40] perspective in a way that illuminates something that you didn’t see before.

[00:13:44] And metaphors provide you a way to understand something that you’ve experienced in the past

[00:13:51] in a much more different way.

[00:13:52] In a more tangible way, you can kind of map your program, your software, to the concepts

[00:14:01] that you physically experienced previously. This is why we use metaphors to name various

[00:14:08] aspects of computer programming. For example, trees. It seems like it’s a core fundamental

[00:14:16] concept, but in fact, it’s a metaphor. It’s a metaphor that we use to understand the

[00:14:22] environment, something that is virtual. I encourage you to watch out for these metaphors

[00:14:29] and to lean on them when you can to create a more physical representation that you can map

[00:14:35] these virtual concepts over. Because the more you can conceptually envision the problem space,

[00:14:43] the more likely you will be able to shift that perspective.

[00:14:48] Thank you so much for listening to today’s episode of Developer Tea. It was our

[00:14:52] third episode in this problem-solving series. I encourage you to go back and listen to the

[00:14:57] first two episodes in the problem-solving series. If you don’t want to miss out on future episodes

[00:15:02] just like this one, where we talk about things like problem-solving and cognitive bias as it

[00:15:08] relates to programming, I encourage you to subscribe in whatever podcasting app you’re

[00:15:13] using right now. Now, if this episode or any other episode has been valuable to you as a listener,

[00:15:20] then you can help give back to the show.

[00:15:22] By going and leaving a review in iTunes. This is the best way to help other developers just like

[00:15:29] you to find Developer Tea. Head over to iTunes, leave a review, leave a rating. That’s super

[00:15:36] helpful. Thank you so much for listening. Thank you again to Linode for sponsoring today’s episode

[00:15:40] of Developer Tea. Linode is giving you a $20 bill. Head over to spec.fm slash Linode and use the code

[00:15:49] developertea2018 at checkout. The most no-brainer investment,

[00:15:52] you can make as a young developer. And of course, if you are developing a large-scale application,

[00:15:59] Linode has you covered as well. Head over to spec.fm slash Linode.

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

Visão de gráfico