Vox

Leitura de 12 min

Default Problem Solving Modes

Summary

In this episode of Developer Tea, host Jonathan Cottrell delves into the critical importance of default problem-solving behaviors for software developers. He argues that our automatic, repeated responses to challenges have a far greater impact on our long-term outcomes than rare, dramatic events. While acknowledging that major life events can be transformative, Cottrell emphasizes that for the average person, inspecting and refining default behaviors is the key to improvement.

Cottrell distinguishes between habits and default behaviors, noting that habits operate automatically with little cognitive overhead, while default behaviors may require conscious thought even though they are our go-to responses. He applies this specifically to software engineering, where problem-solving is rarely on autopilot, making our chosen defaults particularly significant.

The host encourages listeners to identify their own default problem-solving strategies, such as reading code, talking to the person who reported the issue, or consulting the original author. He then challenges developers to consider how these defaults could be improved—for example, by breaking problems down into their smallest components to avoid assumptions and incorrect paths. Cottrell suggests practical methods for self-discovery, including asking coworkers for feedback and consciously observing one’s immediate reactions to new problems.

Ultimately, the episode presents default behaviors not as flaws to be despised, but as tools to be inspected and optimized. By understanding and deliberately adjusting our automatic problem-solving modes, we can become more effective and efficient developers. The episode concludes with actionable homework: investigate your default behaviors and explore ways to enhance them.

Recommendations

Tools

  • Educative — A sponsor of the episode, Educative is recommended as a platform for developers to learn through text-based courses with pre-configured developer environments, allowing for efficient, self-paced learning of new languages, frameworks, and technologies.

Topic Timeline

  • 00:00:00 — Introduction to default problem-solving strategies — Jonathan Cottrell introduces the episode’s core question: what is your default problem-solving strategy in the face of uncertainty? He frames the discussion around the power of repeated, default behaviors over occasional actions, setting the stage for a deep dive into behavioral science principles as they apply to developers.
  • 00:01:45 — Distinguishing habits from default behaviors — Cottrell clarifies an important distinction: habits are automatic and require little cognitive overhead, while default behaviors are our chosen first responses that may still require conscious thought. He notes that very little of a software engineer’s problem-solving happens on autopilot, making the conscious choice of a default mode particularly impactful.
  • 00:04:30 — Identifying your default problem-solving behaviors — After a sponsor message, Cottrell prompts listeners to identify their own default behaviors. He provides examples like reading the relevant code, talking to the person who reported the bug, or consulting the code’s author. The key takeaway is to recognize that first, automatic step you take when confronted with a problem.
  • 00:05:21 — How to improve your default problem-solving — Cottrell moves from identification to improvement, asking how one’s default behavior could be made ‘better’—a term he acknowledges is context-dependent. He proposes one universal improvement: breaking problems into their smallest pieces to understand the lowest level before making assumptions. This counters our tendency to let intuition or memory create incorrect narratives about a problem’s cause.
  • 00:06:49 — Practical homework and seeking external feedback — The host assigns homework: investigate your own default problem-solving behaviors. For those unsure, he suggests asking coworkers, ‘How do you see me typically solving problems?’ He advises looking for convergent themes in the answers and consciously observing your immediate response to new problems as they arise throughout the workday.
  • 00:07:46 — Conclusion: inspecting and changing defaults — Cottrell concludes by reminding listeners that default behaviors originate somewhere, and we shouldn’t despise ourselves for them. Instead, we can inspect them and decide if changing them makes sense. The episode ends with a call to subscribe, review, and thanks to the sponsor, framing the optimization of defaults as a path to better development outcomes.

Episode Info

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

References

Podcast Info

Transcript

[00:00:00] what is your problem solving strategy in the face of uncertainty how do you proceed on average

[00:00:12] that’s what we’re talking about in today’s episode my name is jonathan cutrella you’re

[00:00:16] listening to developer t my goal on this show is to help driven developers like you

[00:00:19] find clarity perspective and purpose in their careers there is power in a default

[00:00:26] this is the underpinning of basically all of the behavioral science books that you’re going to read

[00:00:35] all of the self-improvement books that you’re going to read if you don’t understand this one

[00:00:40] simple principle then none of it’s going to help you because what you do on a regular basis

[00:00:47] has much more power over your results in life over your mood over your

[00:00:55] surroundings

[00:00:56] the things that are repeated have much more of an effect on your life than the things that you do

[00:01:04] once or twice or occasionally now that’s not to say that there are no events that are occasional

[00:01:11] or that happen only once that can’t can have a drastic effect on you of course for example

[00:01:18] a single major accident can leave you paralyzed for example or winning the lottery

[00:01:25] could

[00:01:26] you

[00:01:26] you

[00:01:26] a totally different financial situation than you’re currently in

[00:01:31] but for the average person the most important actions the most important behaviors they can

[00:01:38] inspect are their default ones now in the past on this show i’ve probably made the mistake

[00:01:45] of saying that your default behaviors are one in the same as your habits but there is an important

[00:01:52] difference that we’re going to talk about very briefly and that is that habits are not the same

[00:01:56] habits happen kind of automatically they are a subset of our default behaviors just by nature of

[00:02:04] being a habit but they’re things that happen without us really having to think through it

[00:02:11] our habits don’t require a lot of you know cognitive overhead but default behaviors

[00:02:18] may actually require cognitive overhead just because you have set something up as your default

[00:02:26] response

[00:02:26] in a given scenario doesn’t mean that is that it is easy or that it has become habitual for you

[00:02:34] now it’s possible that you may get into the habit of starting that behavior by default

[00:02:41] if you have that by default behavior you may get into a habit of getting into that behavior before

[00:02:48] you think about it but for software engineers very little of our problem solving is actually

[00:02:54] truly happening and so i’m going to talk a little bit about that in just a moment

[00:02:56] in the sense that it’s on autopilot so if these default behaviors matter then i want you to think

[00:03:04] while we go and talk about a sponsor i want you to think for a moment about what your default

[00:03:10] problem solving behaviors are now let’s take a moment to talk about today’s sponsor

[00:03:17] educative for developers the learning never stops this is something that we’re going to be doing for

[00:03:24] our whole careers there are always some things that we’re going to be doing that are going to be

[00:03:26] a question of time and our goal is to really learn about these new languages frameworks and

[00:03:28] technologies but beyond that being able to apply these and mix them together this is an ongoing

[00:03:35] pursuit the entire time we are developers we’re going to be learning and educative.io is going to

[00:03:38] help you do that educative helps you learn faster and more efficiently because instead of video-based

[00:03:45] courses which require you to scrub back and forth and go at the pace of the video educative uses

[00:03:50] courses that are all text-based so you can skim and double back easily and then swap between them

[00:03:55] if you want to always grab your purpose and then start learning on your own so we’ve talked about

[00:03:56] that today you can take that step and then take that step and start learning on your own you

[00:03:56] can start learning on your own you will mostly use this as a way to keep yourself up to speed

[00:03:56] and then you can start using this as a way to learn as a way to keep yourself up to speed

[00:03:56] go at your own pace, almost like a book. Each course also contains pre-configured developer

[00:04:01] environments so you can practice as you learn and you don’t spend your time doing things that

[00:04:07] don’t matter as much. You can get straight to that learning. They just launched subscriptions

[00:04:11] at almost 50% off. This is a great time to go and check it out. You also get an additional 10% off

[00:04:17] for being a listener of this show. Head over to educative.io slash developer T to get started

[00:04:22] today. Thanks again to Educative for sponsoring today’s episode of developer T. So hopefully you

[00:04:30] can identify what your default problem-solving behaviors are. For example, your default

[00:04:38] problem-solving behavior may be to go and read the code. Read the code that’s associated with

[00:04:44] this particular problem that you’re trying to solve. Or a default behavior might be to talk

[00:04:52] to the person who’s trying to solve the problem. Or a default behavior might be to talk to the

[00:04:52] person who’s trying to solve the problem. Or a default behavior might be to talk to the person who’s

[00:04:52] trying to solve the problem. Or a default behavior might be to talk to the person who told you about

[00:04:54] the problem. Try to learn a little bit more about what they were doing or what they were trying to

[00:05:00] do and what went wrong. Or maybe your default behavior is to talk to the person who wrote the

[00:05:07] code. And there’s a hundred other default behaviors that you could have. But whatever that first step

[00:05:14] is, I want you to consider what that step is, number one. And then number two, how could you

[00:05:21] change your default problem-solving behavior to be better? Better is an ambiguous term because

[00:05:30] everyone who’s listening to the show has a unique scenario where they are solving these problems.

[00:05:36] So the default behavior for one person may not necessarily work well for another person.

[00:05:43] So it depends on your goals and it depends on your context. But consider, and most people have an

[00:05:49] easy answer to this.

[00:05:51] How could your default problem-solving improve? Your default problem-solving behavior improve?

[00:05:56] One way, for example, that it might improve is to break the problem down into its smallest pieces.

[00:06:04] Try to thoroughly understand what’s happening at the lowest level of that problem.

[00:06:12] Very often the opposite happens where we assume a lot about a problem as a way of trying to make

[00:06:18] sense of what’s going on.

[00:06:21] Our reasoning brains are writing the story for us before we can really have evidence to back up our

[00:06:27] story. And we’re using our intuition or our gut or maybe some kind of memory connection about some

[00:06:33] code that is involved in this particular problem. And this can come back to haunt us because our

[00:06:40] assumptions may lead us down entirely wrong paths. Sometimes we’re poring over code that has

[00:06:47] no discernible issue at all.

[00:06:49] So your homework, once again, is to investigate your own default problem-solving behaviors.

[00:06:57] Now, if you’re not sure what they are, one thing you can do is ask your co-workers. Ask them,

[00:07:03] how do you see me typically solving problems? What do you think my kind of mode of operation

[00:07:11] is when I’m trying to solve a problem? You might get some different answers from different people,

[00:07:17] but it’s likely that you’re not going to be able to solve them. So your homework, once again, is to

[00:07:19] find a theme and those answers are going to converge on that theme. As you encounter new

[00:07:25] problems in your job on a day-to-day basis, consider how am I responding to this problem?

[00:07:32] What is my immediate response? The response that I don’t really have to consider deeply. And then

[00:07:39] how could I improve that immediate response? Our default behaviors have come from somewhere and

[00:07:46] we shouldn’t despise ourselves.

[00:07:49] But we can look at those default behaviors and inspect whether or not it might make sense

[00:07:57] to change them. Thanks so much for listening to today’s episode of Developer Tea. Thank you again

[00:08:03] to Educative for sponsoring today’s episode. Head over to educative.io slash developer tea to get

[00:08:09] 10% off of their text-based courses. That’s educative.io slash developer tea. Remember,

[00:08:17] if you don’t want to miss out on future episodes,

[00:08:19] like this one, then go ahead and subscribe to whatever podcasting app you’re currently using.

[00:08:25] And if you want us to continue making this show possible, one way you can help is to go and leave

[00:08:30] a review in iTunes. This helps in two ways. The first way is the obvious one. It gives me clear

[00:08:36] feedback and direction on how to make the show better. But the second one is, well, this one’s

[00:08:42] probably still obvious. This helps other people like you find and decide to listen to Developer Tea.

[00:08:49] Today’s episode was produced by Sarah Jackson. My name is Jonathan Cottrell.

[00:08:53] And until next time, enjoy your tea.

Visão de gráfico