Vox

Leitura de 17 min

Problem Solving Series #2: Reframing

Summary

In this episode of Developer Tea, host Jonathan Cottrell continues the Problem Solving Series by focusing on reframing techniques to enhance debugging and problem-solving. He begins by reflecting on the common experience of memorable debugging sessions, often characterized by overlooking simple errors like a missing semicolon while searching for more complex issues. This sets the stage for introducing two practical framing strategies that developers can apply not only to coding problems but also to interpersonal and systemic challenges in their professional and personal lives.

The first technique discussed is ‘rebuilding your problem.’ Cottrell explains that this involves recreating a simplified, narrow-scope model of the issue to isolate variables and identify the exact point of failure. He uses the example of a browser rendering bug, where copying relevant HTML and CSS into a tool like CodePen and adding elements incrementally can pinpoint the problematic line. The key is to eliminate irrelevant components and focus on the core issue, making the process efficient and effective for smaller, bug-level problems rather than broad design decisions.

The second reframing technique is ‘using a real example.’ Cottrell emphasizes that theoretical models often fall short when confronted with actual user input or behavior. He illustrates this with a front-end form example where performance data might show optimization, but user reports of slowness reveal issues with animation timing in real-world usage. By applying real data and scenarios, developers can better understand how their software performs in practice, challenging assumptions and refining their approaches. Cottrell references statistician George Box’s quote, ‘All models are wrong, but some are useful,’ to underscore the importance of testing theories with practical examples.

Throughout the episode, Cottrell connects these techniques to broader themes of adaptability and bias awareness in problem-solving. He encourages listeners to carry these strategies beyond coding into all areas of life, fostering a mindset of continuous improvement. The episode also includes a sponsorship segment for Bitrise, a mobile continuous integration and delivery platform, highlighting its flexibility and integrations for automating development workflows.

Recommendations

People

  • George Box — A statistician whose quote, ‘All models are wrong, but some are useful,’ is referenced to illustrate the limitations of theoretical models in software development and the importance of testing with real examples.

Tools

  • Bitrise — A mobile continuous integration and delivery platform that automates builds, integrations, and deployments with over 170 integrations, including Slack and shell scripts, allowing teams to streamline their mobile app development workflows.
  • CodePen — Mentioned as a platform for rebuilding and testing front-end code issues, such as HTML and CSS bugs, by isolating components in a simplified environment to identify rendering problems.

Topic Timeline

  • 00:00:00 — Introduction to debugging and problem-solving — Jonathan Cottrell opens by asking listeners about their most memorable debugging sessions, noting that developers often focus on fixing mistakes. He introduces the episode as part of a series on problem-solving, emphasizing its relevance beyond code to interpersonal and systemic issues. The goal is to help developers connect with their career purpose and have a positive influence through effective problem-solving.
  • 00:03:26 — The common debugging story and missing semicolon — Cottrell describes a typical debugging narrative where a developer is called at 2 AM for a server issue, spends hours investigating, and eventually discovers a simple syntax error like a missing semicolon. He points out that these memorable stories often involve unexpected small errors with major consequences. While such scenarios can’t always be avoided, he suggests structuring debugging sessions differently using framing techniques to improve efficiency.
  • 00:05:40 — First reframing technique: Rebuild your problem — Cottrell explains the first technique: rebuilding the problem by creating a simplified model to isolate variables. He uses a browser rendering bug example, where copying HTML and CSS to CodePen and adding elements incrementally helps identify the exact cause. The strategy involves eliminating irrelevant parts and focusing on narrow-scope issues, making it effective for bugs rather than broad design decisions. This process helps pinpoint when and where the problem occurs.
  • 00:10:49 — Second reframing technique: Use a real example — The second technique involves using real data or user input to test software thoroughly. Cottrell gives an example of a front-end form with animations where performance data shows optimization, but user reports indicate slowness due to cumulative animation delays. By applying real examples, developers can see how theoretical models fail in practice. He quotes statistician George Box: ‘All models are wrong, but some are useful,’ highlighting the need to challenge assumptions with practical scenarios.
  • 00:14:29 — Conclusion and encouragement to adapt — Cottrell concludes by encouraging listeners to apply these reframing techniques to become better problem-solvers. He reiterates the importance of being willing to challenge biases and adapt approaches. The episode ends with a reminder to subscribe and check out sponsor Bitrise for mobile continuous integration, reinforcing the theme of practical tools and mindset shifts for developers.

Episode Info

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

References

Podcast Info

Transcript

[00:00:00] what is your most memorable debugging session we talk about debugging on the show a lot because

[00:00:10] a lot of our job as developers is to debug our code most of the time when we write code

[00:00:16] we write it wrong to begin with the rare circumstance where we write a code that

[00:00:23] isn’t wrong to begin with usually that code is doing something really particularly straightforward

[00:00:28] like you know some kind of hello world and I imagine that some of you have actually written

[00:00:33] a broken hello world and from time to time this this happens to every developer in fact

[00:00:41] most of our jobs is about figuring out what we did wrong we’ve talked about this on the show

[00:00:47] before it’s part of the reason why developers need to focus on their wins a little bit more

[00:00:52] than the average person because most of our jobs are focused on fixing our losses

[00:00:58] fixing our losses

[00:00:58] fixing our losses

[00:00:58] our mistakes. But we’re not talking about imposter syndrome or anything like that today. Instead,

[00:01:04] we’re talking about problems. This is the second episode on the discussion about problems. It’s a

[00:01:10] series that we’re doing here on Developer Tea. Problem solving is in and of itself a skill.

[00:01:17] In fact, it’s a conglomeration of a lot of different skills. And that’s why we are focusing

[00:01:22] on it for a couple of episodes on the show. My name is Jonathan Cottrell and you’re listening

[00:01:26] to Developer Tea. My goal on the show is to help driven developers connect to their career purpose

[00:01:31] and do better work so they can have a positive influence on the people around them. And what

[00:01:37] better way to have a positive influence as quickly as possible than solving a problem?

[00:01:43] Now the problems that we’re talking about solving in today’s episode, we’re talking mostly about

[00:01:48] solving a problem in code. That’s kind of the lens that we use. But really these techniques,

[00:01:55] they go well beyond.

[00:01:57] Problems just in code. They apply to interpersonal problems. They apply to systematic problems

[00:02:03] outside of the realm of software development. So I encourage you to carry this information forward

[00:02:09] outside of your daily practice as a software developer and into your life as just a human

[00:02:15] being, but also your professional life beyond the code. And I asked you about your most memorable

[00:02:22] debugging session because for most people, the story,

[00:02:26] sounds a little bit like this. While I was asleep and somebody called me at 2 a.m. and

[00:02:33] the server had gone down. We’re trying to figure out why the server had gone down. And

[00:02:38] so I wake up and I run to my computer and it takes five hours of me debugging and trying to

[00:02:45] figure out, you know, digging through these logs or looking through our last couple of commits.

[00:02:50] Nothing seems to be standing out to me. And then suddenly I notice I’m missing,

[00:02:56] semicolon. And of course, my brain wasn’t on the semicolon the whole time. I was looking for

[00:03:02] the more technical problem, the memory overflow errors or some major DDoS attack. I was looking

[00:03:10] at the big picture when really all that was happening was a simple syntax error. This happens

[00:03:18] all the time, doesn’t it? These are the most memorable stories because perhaps the most

[00:03:22] unexpected thing occurs.

[00:03:26] And it has these major consequences. Now, while you’re not going to be able to avoid every time

[00:03:33] that you have ever written a missing semicolon, you’re not going to be able to avoid every single

[00:03:37] scenario like that. What you can do is structure your debugging sessions a little bit differently.

[00:03:44] In today’s episode, we’re going to be talking about two different framing techniques for you

[00:03:50] to debug better. We’re going to do that right after we talk about today’s sponsor, Bitrise.

[00:03:55] If you want to learn more about Bitrise, go to bitrise.com.

[00:03:56] If you want mobile continuous integration and delivery for your team, go and check out Bitrise.

[00:04:03] Bitrise allows you to take all of the services that you already use and that you’re probably

[00:04:08] using one at a time, manually triggering a build in one place and then sending a post request to a

[00:04:16] server somewhere else and then uploading all of this code to the Google App Store and writing all

[00:04:23] of your release notes, doing all of that manually.

[00:04:26] Bitrise allows you to create a single, simple, automated solution for all of those things to

[00:04:34] happen together. It’s kind of like if this than that, but much more powerful and specifically

[00:04:41] made for mobile app development. There’s over 170 integrations that you can use.

[00:04:47] And we’re not just talking about the big app integrations that most things have,

[00:04:53] for example, sending a Slack message. Of course, that’s available.

[00:04:56] In Bitrise, but you can also do much lower level things like, for example, running a shell script.

[00:05:03] So the power of the platform can’t be overstated because it’s so flexible.

[00:05:08] And beyond being flexible, it’s also easy to share your integration setup.

[00:05:14] You can share your configuration because all of these services, once you kind of strap them

[00:05:20] together, you can download that integration configuration as a Bitrise.yaml file.

[00:05:26] So this is easily ported to everybody’s local environment.

[00:05:30] Go and check out what Bitrise has to offer. Head over to spec.fm slash Bitrise.

[00:05:35] Thank you again to Bitrise for sponsoring today’s episode of Developer Tea.

[00:05:40] So we’re talking about different ways of framing your debugging sessions and more broadly,

[00:05:46] different ways to frame problems and trying to understand the problem really is what we’re

[00:05:52] talking about. There’s a lot of ways to understand problems.

[00:05:56] It’s not easily stated and there’s a lot of kind of famous quotes about this that a well-described

[00:06:04] problem is halfway solved. That’s been attributed to pretty much everybody under the sun.

[00:06:10] So what are some ways that we can debug better? How can we bring in some new perspective on how

[00:06:17] to frame a problem? I’m going to share two framing techniques that I have used successfully in the

[00:06:22] past and that other developers have certainly used as well.

[00:06:26] Again, these are framing techniques that will work outside of the realm

[00:06:29] of software development as well. So the first one is to rebuild your problem.

[00:06:36] Rebuild your problem. This sounds like it’s going to take a lot of time, but

[00:06:41] I want to focus on a specific aspect of this that I think is really often missed.

[00:06:47] And that is to take the things that you think are contributing to your problem and rebuild them

[00:06:55] in a very straightforward way. So let’s start with the first one.

[00:06:56] Let’s start with the first one. Let’s start with the first one.

[00:06:56] Let’s start with the first one. Let’s start with the first one.

[00:06:56] I’ll give you an example of this. Whenever I am facing a strange browser rendering bug,

[00:07:04] right in the browser, I have something that I’ve created. I have some kind of HTML and some CSS.

[00:07:11] And for whatever reason, it’s not showing up how I expect it to be showing up. Something is not

[00:07:17] working like I expect it to work. I take out the relevant kind of mini pieces, right? So I

[00:07:26] take out the relevant HTML and I copy the relevant CSS and I bring it over into a different platform,

[00:07:33] something like CodePen, for example, right? And I drop that HTML in, I drop that CSS in,

[00:07:40] and I try to identify and eliminate as many variables as I can to see if the things that

[00:07:48] I think are contributing to the problem are actually contributing to the problem.

[00:07:53] And this process of elimination is kind of,

[00:07:56] a theme of problem solving. You’re eliminating variables as you go along. One of the ways that

[00:08:04] you’re going to eliminate variables is through this recreation process. As you recreate each of

[00:08:10] the pieces of the puzzle, what you’ll find is that you’re more able to identify when that problem

[00:08:18] showed up, right? So you’re adding things in our browser rendering bug, for example,

[00:08:23] that you’re starting to add the HTML and you add the CSS. Maybe you add it one rule at a time or

[00:08:29] one declaration at a time. And as you’re adding it, everything looks right until this particular

[00:08:36] line. This is a really effective problem solving strategy, especially when you’re doing something

[00:08:42] that is easily rendered. In other words, you’re going to get some quick feedback, right? So you

[00:08:48] can easily see which particular thing that you did.

[00:08:53] Led you astray. Rebuild your problem. Now, the way that you keep this from being really expensive

[00:08:59] and time consuming is by eliminating things that are irrelevant. So for example, let’s say you

[00:09:07] are getting some information from a database and you know that that information is being pulled in

[00:09:13] reliably. You’ve identified that that information, that that’s not where your problem is actually

[00:09:19] coming from. And you’ve verified that. Well, now you don’t necessarily need to

[00:09:23] rewrite a connection to a database. You can just take the data itself, the static data,

[00:09:29] and plug it in statically. So now you kind of cut down the complexity of your kind of rebuilt

[00:09:37] problem space. It’s also important to remember that this is going to work particularly well

[00:09:43] for narrow scope problems, much smaller problems, things that you would probably consider bugs

[00:09:51] rather than, you know, an entire design.

[00:09:53] Decision or design domain. That’s not really what we’re talking about. We’re talking about

[00:09:58] figuring out some kind of confounding bug. So that’s the first reframing technique. Rebuild

[00:10:05] your problem. Now, I want to add on to this because I still feel like this concept is a

[00:10:11] little bit difficult to grasp. Really what you’re doing is you want to create kind of a miniature

[00:10:15] model of your problem. You’re not recreating all of the details. You’re creating something

[00:10:22] that tests a very narrow portion of what you had created originally, right? It’s almost like

[00:10:31] creating a prototype that highlights a specific set of functionality. Okay, let’s move on to

[00:10:40] reframing technique number two. Use a real example. Use a real example. This is something

[00:10:49] that developers very often forget.

[00:10:52] Forget or ignore because it can be a little bit difficult. Using a real example often means

[00:10:59] taking real data, for example, user input, right? Or even user behavior, taking that real information

[00:11:08] and identifying how your program, how your software interacts with that information.

[00:11:16] And here’s why this is so important, especially when we’re talking about software that deals with

[00:11:20] some kind of input.

[00:11:22] Some kind of interaction. Until you actually use real information, real input, you’re not actually

[00:11:30] seeing, you’re not testing the software thoroughly. I’ll give you a very simple example. Let’s say

[00:11:36] you’re a front-end developer and you’ve created an interface. And the interface kind of gives some

[00:11:43] transitions between form elements. As you fill out one form element, it kind of fades out and a new

[00:11:50] form element comes in.

[00:11:52] Receiving bug reports that are saying, yeah, this form is very slow. And you know from your

[00:11:59] performance data, you can look at the performance data and everything is optimized and you can’t

[00:12:04] quite connect the dots between what these people are saying. The form is very slow and actually the

[00:12:11] data says it’s not very slow. In this case, what these reports are likely referring to is how long

[00:12:20] these animations are taking.

[00:12:22] In other words, it’s taking such a long time between filling out one field and the next field

[00:12:28] that by the time I get to field number 10, I’ve spent so much longer on this form than I really

[00:12:34] wanted to spend. Now taken in a single snapshot view, one of those form inputs might have felt

[00:12:42] quite nice. It might have felt like it was designed well. But when you take a real example,

[00:12:48] when you take a real person who is spending the time to create a form, you’re not really

[00:12:52] filling out this form. Well, now, regardless of how nice that one interaction was, these reports

[00:13:00] of the form being slow, they suddenly make sense. The underlying principle or system at play here

[00:13:07] is that everything in practice requires more than theory. Everything that we build as software

[00:13:17] developers, even though it is informed by some kind of theory, it’s not necessarily a theory.

[00:13:22] Theoretical model. We must apply real examples to know how thoroughly those theoretical models

[00:13:31] are covering us. There’s a famous quote that is attributed to statistician George Box. The quote

[00:13:38] goes something like this. All models are wrong, but some are useful anyway. In some ways, this

[00:13:47] can be applied to theory, especially as it relates to software development.

[00:13:52] In particular, software development for human interaction. We have theories of how humans

[00:14:00] should interact with our software. And yet, so often, real examples challenge those theories or

[00:14:08] they take them to their very limit. And so we must be willing to accept that as we practice

[00:14:18] with real examples, our theories may only prove to be true.

[00:14:22] But we also have to accept that we only provide some support rather than imperative direction.

[00:14:29] Thank you so much for listening to today’s episode of Developer Tea. I hope that I can help you solve problems

[00:14:35] better through things like reframing techniques. If you want to learn more about problem solving and a thousand

[00:14:41] other topics that are relevant to not only software developers, but anyone really who wants to become

[00:14:47] better at what they do and is willing to challenge the status quo and willing to adapt and to

[00:14:52] Admit that their minds are biased and that their approaches are not necessarily always going to be good just because they want them to be.

[00:15:02] That’s the kind of things we talk about on this show.

[00:15:05] Please subscribe in whatever podcasting app you’re using.

[00:15:09] And while you’re at it, go and check out Bitrise.

[00:15:11] Head over to spec.fm slash Bitrise.

[00:15:14] Bitrise is continuous mobile integration and delivery for your team.

[00:15:19] Once again, spec.fm slash Bitrise.

[00:15:22] Thank you so much for listening to today’s episode of Developer Tea.

[00:15:26] Until next time, enjoy your tea.

Visão de gráfico