Vox

Leitura de 19 min

Two Incredibly Important Mindsets for Becoming a Great Debugger

Summary

In this episode of Developer Tea, host Jonathan Cottrell explores two fundamental mindsets that can dramatically improve debugging skills for developers. He begins by drawing an analogy between debugging and his grandfather’s mechanical expertise, highlighting how careful observation of normal system behavior is crucial for identifying anomalies.

The first mindset emphasizes paying close attention to how systems look and feel when they’re working correctly. Cottrell explains that by developing an intimate understanding of normal system behavior—including load times, log messages, and data patterns—developers can more quickly recognize when something has gone wrong. He compares this to medical professionals who look for changes in health rather than just current symptoms.

The second mindset focuses on shortening and hyper-focusing feedback loops in the development process. Cottrell advocates for making minimal changes—ideally one at a time—and immediately testing each change to understand its impact. This approach creates a direct connection between code modifications and their effects, making it easier to identify the source of bugs.

Cottrell addresses potential objections about time constraints, arguing that this approach actually saves time in the long run by catching errors earlier, reducing stress, and improving code quality. He mentions tools like live reload and automated testing suites that can facilitate shorter feedback loops.

Throughout the episode, Cottrell emphasizes that these mindsets are language- and platform-agnostic, making them valuable for developers regardless of their specific technical stack. The episode concludes with a recap of both mindsets and their practical applications in everyday development work.

Recommendations

Services

  • Linode — Sponsor offering SSD cloud servers with Linux distributions, starting at 20 credit for Developer Tea listeners using code ‘developertea20’.

Tools

  • Live Reload — Mentioned as a tool for front-end developers to automatically refresh the browser when code changes are saved, facilitating shorter feedback loops during development.

Topic Timeline

  • 00:00:00 — Introduction to debugging mindsets — Jonathan Cottrell introduces the episode’s focus on two mindsets that will help developers become better debuggers. He draws a parallel between debugging and mechanical work, sharing a story about his grandfather’s ability to diagnose car problems just by listening to descriptions of symptoms.
  • 00:04:25 — First mindset: Observe normal system behavior — Cottrell presents the first mindset: paying close attention to how systems look and feel when they’re working correctly. He explains that understanding normal behavior helps developers recognize anomalies more quickly. The analogy extends to doctors who ask about changes in health rather than just current symptoms.
  • 00:07:01 — Practical example of system observation — Cottrell provides a concrete example: if a website’s load time suddenly triples, developers who haven’t been observing normal behavior might not recognize the problem. He mentions real-world scenarios like oversized images or servers rebooting with each request as issues that become apparent only when you know what ‘normal’ looks like.
  • 00:08:31 — Second mindset: Shorten feedback loops — The second mindset involves shortening and hyper-focusing feedback loops by making minimal changes and testing immediately. Cottrell contrasts this with the common practice of making multiple changes before testing, which makes it difficult to identify which change caused a problem.
  • 00:10:57 — Addressing objections and benefits — Cottrell addresses the objection that testing after every change is time-consuming, arguing that it actually saves time long-term by catching errors earlier. He notes benefits including reduced stress, increased dependability, and improved code quality. Tools like live reload and automated testing can facilitate this approach.
  • 00:13:50 — Recap and conclusion — Cottrell recaps both mindsets: learning how systems look when working normally, and shortening feedback loops by testing changes incrementally. He emphasizes that these approaches will make developers better debuggers regardless of their specific technology stack.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2016-04-08T07:00:00Z
  • Duration: 00:15:41

References

Podcast Info

Transcript

[00:00:00] Hey, everyone, and welcome to developer team. My name is Jonathan Cottrell. And in today’s episode, I’m going to talk to you about two mindsets that will help you in your debugging. This is something that is a part of every developer’s life and a part of each and every moment of our day, whether or not we know it. So we’re going to dive into that content in just a second. Today’s episode is sponsored by Linode.

[00:00:29] If you are looking for an SSD server that has Linux pretty much prepackaged for you ready to go out of the box, and you want to get up and running quickly with low cost monthly plans, check out Linode.

[00:00:43] You can find a special offer for developer team listeners, which we will discuss a little bit more later in the show by going to linode.com slash developer team. Again, we’ll talk more about Linode later on in the episode.

[00:00:57] But I want to start with a story.

[00:01:00] My dad recently told me a story about him and his father when he was younger, when my dad was, you know, probably in his teenage years.

[00:01:10] And he was telling me about how his dad was a really great mechanic.

[00:01:14] And he could come into the house and he’d be working on a car in the garage.

[00:01:19] He’d come in and sit down with his dad and have a cup of coffee.

[00:01:22] And he would detail what he was doing on the car to my grandparents.

[00:01:27] We called him Papa.

[00:01:30] My dad would talk to Papa and he would tell him what was happening with the car, what he was experiencing, the trouble he was having and the issues that he was facing.

[00:01:39] And Papa would tell him, you know, go and do this one thing real quick and then come back and tell me what happens.

[00:01:46] And just by listening to what my dad had to say, he could help him fix the car.

[00:01:52] And in fact, very often he would know exactly what was wrong with the car.

[00:01:57] Just by listening.

[00:01:57] Just by listening to a few descriptors from what my dad said and also listening to what my dad said after he changed the things that Papa asked him to change.

[00:02:07] You know, a good developer and a good mechanic share quite a few qualities.

[00:02:13] And we do some very similar work at a fundamental level.

[00:02:17] We’re looking at a system.

[00:02:19] We’re looking at something that is supposed to work in a particular way.

[00:02:23] And we’re trying to find the things that are wrong, the things that are preventing it from working.

[00:02:27] In that particular way.

[00:02:29] So I’m going to give you two mindsets in just a moment after we talk about our sponsor.

[00:02:34] Two mindsets that will help you forever in the process of debugging.

[00:02:39] These are things that are never going to expire.

[00:02:43] They aren’t about a particular language.

[00:02:44] They aren’t about a particular platform.

[00:02:47] It’s actually just ways of thinking that will make you a better debugger.

[00:02:52] We’re going to talk about that in just a second.

[00:02:54] But first I want to talk about today’s sponsor, Linode.

[00:02:57] With Linode, you can instantly deploy and manage an SSD server in the Linode cloud.

[00:03:04] You can get a server running in just seconds with your choice of Linux distribution, resources, and node location.

[00:03:11] Now you get to pick from eight different data centers.

[00:03:14] And their plans start at just $10 a month.

[00:03:16] That’s like two coffees.

[00:03:18] You can get a server running in just under a minute.

[00:03:20] They have hourly billing with a monthly cap on all of their plans and on their add-on services.

[00:03:26] That includes backups.

[00:03:27] No balancers and long view.

[00:03:30] And you have virtual machines for full control.

[00:03:32] You can run a Docker container.

[00:03:34] You can do an encrypted disk.

[00:03:36] They have VPNs.

[00:03:37] You can set up a private Git server even.

[00:03:41] And Linode is not cheaping out on the speed.

[00:03:43] They have native SSD storage, a 40 gigabit network, and Intel E5 processors on all of their machines.

[00:03:51] So check it out.

[00:03:52] Linode.com slash developer T.

[00:03:54] They have a seven-day money-back guarantee.

[00:03:57] If you go to that link that I just said, linode.com slash developer T,

[00:04:02] or you use the code developer T20 at checkout,

[00:04:05] Linode is providing you with a $20 credit just for being a developer T listener.

[00:04:12] So go and check it out, linode.com slash developer T.

[00:04:15] Thank you so much to Linode for sponsoring today’s episode of developer T.

[00:04:19] So I promised you two ways of thinking, two mindsets that you can have

[00:04:25] that will make you a better debugger.

[00:04:27] And I don’t mean just slightly better.

[00:04:29] I mean leaps and bounds better.

[00:04:32] You will be a much better debugger and ultimately a much better developer

[00:04:37] if you adopt these two mindsets, okay?

[00:04:41] So the first mindset, and I would say that these are worth writing down actually.

[00:04:45] So grab a piece of paper and a pen or open your notes app or whatever it is that you take notes in.

[00:04:50] The first mindset is that you are paying very close attention

[00:04:55] to how things look.

[00:04:57] When they’re running right.

[00:05:00] You are paying very close attention to how your system looks when it is running right.

[00:05:07] When it is relatively bug free.

[00:05:10] You know what working software looks like when it is bug free.

[00:05:14] Now let me expound a little bit on this.

[00:05:17] Most of the time, if you’re writing sufficiently good code,

[00:05:21] your code is working properly.

[00:05:24] Most of the time, things are going right.

[00:05:27] Now, if you’re writing sufficiently good code,

[00:05:27] Now, if you encounter a bug,

[00:05:30] then knowing what caused that bug

[00:05:32] is ultimately the path towards understanding how to fix that bug.

[00:05:38] And if you know when that bug starts occurring,

[00:05:42] in other words, if you know exactly what the system looked like just before the bug,

[00:05:48] if you know what the system is supposed to look like regularly,

[00:05:51] then you have a unique ability to recognize when it doesn’t look regular.

[00:05:57] When it doesn’t show all of the signs of a normal working system.

[00:06:03] This is a universal concept throughout many different fields.

[00:06:07] We talked about mechanics before,

[00:06:10] but also think about a doctor, for example.

[00:06:13] One of the first things that they will ask you at a yearly checkup

[00:06:17] is have you had any changes in your health?

[00:06:21] Not how do you feel,

[00:06:23] but rather have you had any changes?

[00:06:26] Because changes are a big part of your life.

[00:06:27] And changes are a big part of your life.

[00:06:27] Because changes are a big part of your life.

[00:06:27] Because changes are a big part of your life.

[00:06:27] Because changes are a big part of your life.

[00:06:27] Because changes are a big part of your life.

[00:06:27] are the things that ultimately show us when something has shifted from a working state to

[00:06:34] a non-working state. And it’s illogical, right? We can understand that bugs are introduced and

[00:06:40] then the system changes. And if we’re highly tuned, if we pay attention very closely to how

[00:06:47] things work when they are working properly, how things look, how they feel when they’re working

[00:06:53] properly, then we will be able to more quickly recognize when a bug is introduced. For example,

[00:07:01] if you are creating a website and you notice all of a sudden that the load time just increased by

[00:07:09] two or three times, but you’re not paying attention to that, maybe you are not, maybe you

[00:07:15] hadn’t heard this episode of Developer Tea and you weren’t paying attention before, you weren’t

[00:07:19] paying attention to how long it took to load when the code was created.

[00:07:23] Correct before, then you may not even recognize that there’s something that’s loading two or three

[00:07:28] times more than it needs to be loading. You may not recognize that you’re loading a image that

[00:07:34] is far too large, or maybe as I saw in a tweet earlier this week, you may not realize that your

[00:07:39] server is having to reboot for every single request that’s coming into that server. So this is

[00:07:46] something to keep in mind is these little nuances, right? The details of how things look, how things

[00:07:52] feel, what type of data you’re using, what type of data you’re using, what type of data you’re using,

[00:07:53] what types of log messages are you getting when things are correct, and then what types of log

[00:07:58] messages do you get when an error is introduced. Most of the time, bugs are introduced by code.

[00:08:05] Most of the time, a bug is caused by either a third-party package being pulled in or updated

[00:08:11] in your code and then, you know, breaking something, making it incompatible, or you yourself,

[00:08:17] you’re writing some code and then you introduce a bug. And that leads us directly into our second

[00:08:23] mindset for becoming a master debugger, a fantastic developer when it comes to debugging,

[00:08:31] and that is to shorten and hyper-focus your feedback loop. Shorten and hyper-focus your

[00:08:39] feedback loop. And this concept of a feedback loop may be a little bit foreign to some of you,

[00:08:44] but the idea here is that you have a working system, so let’s say a code base, maybe you’re

[00:08:49] building an app, and you’re adding inputs.

[00:08:53] This is the initial signal. You’re adding inputs. You’re changing code. You’re doing something

[00:08:58] to modify that system. Well, a lot of times, we have the tendency to modify the system

[00:09:04] in three or four or 10 or 20 ways and then check and see what happens once we’ve done

[00:09:12] those modifications, right? So we write a bunch of code and then we go and test that code after

[00:09:18] the fact. Now, the problem with this is that if something goes wrong,

[00:09:23] well, which line of code caused it? And of course, with some sufficient log messages,

[00:09:29] you may be able to follow the backtrace. You may be able to figure it out. But a much more

[00:09:35] effective way to work is to make fewer changes, much fewer changes, in fact, one change at a time,

[00:09:43] and then go and test that change. This is a continuous testing process. And you may be

[00:09:49] running your tests automatically, or you could just be testing it.

[00:09:53] Testing how something looks in the browser. So the idea here of a short feedback loop is to make

[00:09:59] as small of a change as possible and then see what that change did to the system. Take a look

[00:10:06] at what that change caused in the system. Now, why is this so important? Well, like I said before,

[00:10:13] every single bug, pretty much every single bug that you’re going to encounter is likely going

[00:10:18] to be caused by your code. You’re going to write the bug,

[00:10:23] and if you ship something that is broken, then you may not know that it’s broken right away.

[00:10:29] You could ship three or four features before you know that it’s broken. Now, when you shorten that

[00:10:34] feedback loop, then you know what the effect is of every single line of code that you write.

[00:10:41] So what we want to do is shorten the feedback loop so that we have a direct connection

[00:10:46] between when an error occurs and what line of code is causing that error to occur.

[00:10:52] Now, the first thing we want to do is shorten the feedback loop so that we have a direct

[00:10:53] connection between when an error occurs and what line of code is causing that error to occur.

[00:10:53] Now, the first bit of pushback that you may have when you hear this, this concept of shortening

[00:10:57] the feedback loop, you may think, well, I don’t have time to test after every single change.

[00:11:03] And the reality is that that feels true on the front end, right? It feels like we’re having to

[00:11:09] go through this very laborious process of constant feedback loop where we’re testing after every

[00:11:15] single change. But there’s a few things at play here. Number one, you’re going to save time in

[00:11:21] the long run.

[00:11:22] Because the errors that you find, you’re going to find them more often, you’re going to find them

[00:11:27] in the development process, rather than them getting shipped. And beyond that, you’re going

[00:11:32] to save you and or your clients a lot of money, because the server is not going to go down,

[00:11:39] right? You’re not going to lose business for that client. You’re not going to lose business

[00:11:43] for yourself if you’re creating a product. By doing this testing process, you reduce

[00:11:47] the total number of errors in your code. And ultimately, your stress is going to go down.

[00:11:52] It’s going to go way down. And your dependability on your development process is going to go

[00:11:58] way up. This short feedback loop style of coding also greatly increases the quality of your code

[00:12:06] on a regular basis. You’re going to have much better output the first time that you write code

[00:12:12] once you get into this rhythm. Now, with that said, there are quite a few tools that can help

[00:12:17] you with this kind of constant testing process. For example, if you’re doing a lot of front-end

[00:12:22] work, you probably want to invest in something like live reload, bringing that into your process

[00:12:28] so that whenever you save, and maybe you’re compiling your JavaScript or you’re compiling

[00:12:33] your SAS or LESS or something like that, whenever you save, it will live reload in the browser.

[00:12:38] Of course, I will include a link in the show notes to live reload. But there are a lot of

[00:12:44] these kinds of things. For example, you can automatically run your tests whenever you save

[00:12:50] a new test. If you’re working on a new test, you can automatically run your tests whenever you save

[00:12:52] on a Rails project or another project that has a software test suite. So there’s a lot of tooling

[00:12:59] around this concept of a very short feedback loop. I highly recommend that you invest in a short

[00:13:05] feedback loop. I can’t tell you how many times developers that I work with, they come to me and

[00:13:11] they tell me that they have an error, but they don’t know where it came from. And notoriously,

[00:13:16] almost every single time, it’s because they had a very long amount of work that they were testing.

[00:13:21] They weren’t testing one thing at a time. They were doing a bunch of changes on their local

[00:13:27] computer, for example, and then pushing up everything all at once, rather than pushing

[00:13:31] it up in increments and testing each of those individual features. And so they had to go back

[00:13:38] and reconfigure and roll back everything to 20 features before, rather than saying,

[00:13:44] oh, it’s that one feature and rolling back just that one. So again, let’s do a quick recap.

[00:13:50] There are two mindsets that

[00:13:51] I want you to adopt to become a better debugger. And the first one is to focus very, very intently.

[00:14:00] Learn how a system feels and how it looks when it is working normally. So number one,

[00:14:08] learn how a system looks and feels when it is working normally, when there’s nothing wrong

[00:14:13] with it, when you don’t see bugs present. And number two, shorten your feedback loop.

[00:14:20] Make it very, very fast.

[00:14:21] Focused one change at most, maybe two or three changes at a time, and then check what that did

[00:14:28] to the system. See your test reports or reload it in the browser. See what is happening for each of

[00:14:34] those changes. Thank you so much for listening to Developer Tea. I hope you’ve enjoyed this episode

[00:14:40] and hopefully your debugging will continue to get better as you gain more experience,

[00:14:46] as you practice these ideas of learning how a system feels

[00:14:50] when it’s in its normal state, when it’s working well, and also shortening your feedback loops.

[00:14:56] Thank you so much to Linode for sponsoring today’s episode. If you’re looking for a cloud hosting

[00:15:01] provider specifically for Linux, and you want a $20 credit for free just for being a Developer

[00:15:08] Tea listener, go to linode.com slash developer tea, or you can use the code developer tea 20

[00:15:15] at checkout at linode.com. Thanks so much to Linode.

[00:15:19] Thank you for listening.

[00:15:20] Thank you for listening to the show. Of course, you can always leave a rating and review for

[00:15:24] Developer Tea in iTunes. This is the best way to help other developers just like you

[00:15:30] find Developer Tea. Thanks so much for listening. And until next time, enjoy your tea.

Visão de gráfico