Troubleshooting is a Lifestyle 😎 with Jack Linke

Speaker 1: All right. Well, thank you for coming to my talk. Troubleshooting is a lifestyle. And I hope I'll be able to convince you of that. Before we get started, a couple things about me. So my name, Jack. I'm the managing director of a small business called Watervise. build data systems for irrigation districts, helping them with their operations. I'm a radar maintenance officer when I'm not working on that business. My my real job is is as a maintenance officer in the Marine Corps. I work on radars, supervising a team who keep those things running. I'm a husband, I'm a father, and here's my baby.

Speaker 1: And if you think this whole talk is an excuse to show pictures of my dog, it may be So my background. I've been programming for many years. As a kid I was programming. I was fortunate my grandparents got us a computer, an old 386 when I was just a young kid. So I've been programming off and on pretty much my whole life. Professionally now, really for the last six years. I got uh started with Django. Uh when I started this business, and I've loved it ever since. I've also worked on radar systems, so I was a technician for many years before I became a maintenance officer. Responsible for making sure that systems that are tracking uh millions

Speaker 1: of cubic miles of airspace, routing people from place to place, uh, that we have eyes on everything that's going on. And I've worked with electronics, uh designing electronics when the open source hardware movement was kind of first starting out. Um I I was doing a lot of electronics design at the time. So I've had many different opportunities to do uh troubleshooting in in various fields. Some of the things I've worked on, mechanical and power systems, digital and analog electronics, RF systems, just kind of the whole swath of things, including embedded uh software. And obviously desktop and web software with Python and Django.

Speaker 1: So the goals of this talk I'm not going to make you expert troubleshooters in 45 minutes. I don't think that's a possibility in any world Many of you are already probably really good troubleshooters. My goal here is that the beginners, folks who have not had a lot of experience with troubleshooting, have some new tools in their bag. And people who have been troubleshooting for a while have an opportunity to think through some of the ways that they can make themselves better. At the end of the day, Troubleshooting is a skill. It's not something that 's innate in any of us. Um and just like any skill, the more you practice it and the better tools you have, the better uh trainings you have

Speaker 1: The better you're gonna be at it. So let me tell you about a bad troubleshooting experience Years ago, I was responsible for evaluating a team of folks who were setting up a communications site out in the desert. And their one goal was to set up the site and be able to communicate to another location uh on an airfield. And when I got to that location, they had put up Not one, not two, but four different antennas. They only needed to establish one link, but they had four antennas up. And so we started asking them what 's going on. Four very different types of antennas. If you're familiar with with radios, they had a loop antenna, they had a sloping V, like all sorts of different things.

Speaker 1: And when we started asking them what was going on, well, they told us, you know, the first one we set up and it didn't work. Uh so we moved on and we set up a second one. And so on and so forth. And when we looked at the antennas, like the the wire lengths weren't correct, they weren't grounded, there was there was some some obvious things that steps that they could have done to To identify what the cause of each one of these antennas not working. But but they didn't do that. And so I asked the person responsible, You know what what what are you guys using to build these antennas? Where's your manuals? And he looked at me with a completely deadpan face and said, Sir , I don't need manuals. I rely on experience.

Speaker 1: So I would not recommend that as your troubleshooting experience. That's an example of what is often called shotgun troubleshooting or shotgun debugging, where you you uh if if you're ever doing like marksmanship, you you don't want to use a shotgun. It it scatters the shot. all over the place. You would want something more precise. And that's where the background of that that term comes from. Anytime you're you're troubleshooting and You're not decisively and with good reason making a change in something. That that's shotgun uh troubleshooting. So hopefully by the end of this talk, none of us will be doing that. We'll be using tools that are more appropriate to

Speaker 1: the job. I just want to encourage you guys with the right tools, with the right techniques, the right indicators, there's always a way, no matter what system you're working on, whether it's you know something in the Django web framework. or any other uh field or aspect out there, there is a way to troubleshoot a problem that makes sense and will get you to a solution. So before we really get into it, a few terms. So problem solving is the first thing that we'll talk about, and problem solving is sort of a broad term for whether whether it's troubleshooting, which is a subset, or whether you're just thinking through a problem, problem solving is a really broad thing.

Speaker 1: We've we've got a A thing or a problem or something that we want to approach, and how do we get there? It doesn't necessarily involve something tangible like a circuit board or a keyboard and computer. It could just be thinking through a problem. You know, I've got a problem in my relationship. How do I resolve that? More specifically though, troubleshooting, it's a subset and it's It's about recognizing that there is a problem. That's really the first step. Recognizing that there is a problem, locating that problem, and then resolving it. And the last thing, debugging, which uh I'm sure we're all familiar with that term. Um it 's really a subset then of troubleshooting, and I'll use it pretty much interchangeably through this talk.

Speaker 1: Uh Either either troubleshooting or or debugging. So the first thing is getting the right mindset. When it comes to troubleshooting, like I said, it's it's it's a skill, but it's not just a skill. It's something that all of us do throughout our lives, and not just the people in this room, every human being is troubleshooting or problem solving also throughout their lives. So a quick lesson from Curious George, in case you think that I'm not telling you the truth. We we learn these things from the very beginning. So, Curious George was supposed to be delivering some newspapers. Uh, instead of delivering them, he thought it would be interesting to make some boats. So he made boats of them, put them in the river, and

Speaker 1: he'll have to figure out how to get those delivered at another time. We're not going to go through that. But as he was watching his boats, he wasn't looking where he was going. He hits a rock, he falls in the river, gets himself out, and now he can't ride his bike. So the first step, identifying what the problem is, he's got a vent wheel. He's located the problem. And he thinks through what he can do. Well, he can ride a wheelie. He's a pretty talented monkey, and he makes his way and the story resolves itself later on. But this is just an example, every or just about every children's book out there has some sort of problem that you gotta work through and think through and gives us examples.

Speaker 1: So it's a skill that you learn early in life, but we can get better at it over time. It's everywhere. In medicine, doctors have to figure out from a certain set of context clues from potentially from the the uh victim themselves. uh from the instruments that they have, they have to figure out what's what's wrong and how to resolve it. In aviation , There's all sorts of scary things that can happen if people aren't troubleshooting and looking for the problems, identifying where those problems are and then resolving them. uh military, tech, you can name just about any industry that's ever been, and there's troubleshooting involved.

Speaker 1: So when it comes to the mindset for troubleshooting, it's important to be persistent and curious. Some problems are really easy to solve, some not so much. If you if you just give up, I mean you're you're you're gonna be in a tough spot. Uh and if you're not curious and and thinking about what What direction this problem might have taken, that can be a problem too. So on to some of the more practical things. Up till now, we've just been talking about some of the philosophical or background uh information about troubleshooting. But the next three sections, I really want to get into kind of the meat of it So indicators and resources.

Speaker 1: Most of us are familiar with indicators in in Django to some extent. And in other areas of your life, when you're troubleshooting, you you might be familiar with some of the indicators out there. When I'm talking about indicators, what I mean is anything that can give you information about the context of that problem that you're trying to solve. If your only tool is a hammer, then every problem looks like a nail. I found this quote recently. Uh we've all heard it a million times, but I didn't realize it was by Abraham Maslow, the same uh guy who who developed out uh meslow's hierarchy. Um but a really great quote if if you're using the same indicators To solve all your problems, if you're just sticking with the basics,

Speaker 1: you're never gonna have the context when you run into a deep problem. You're never never gonna be able to really dig in and solve that problem. So some of the ways that we can think about indicators, again, regardless of what industry, but but for Django, uh this is very relevant. Built-in versus extra. So Django comes with some built-in indicators that we can use. And there's a bunch of extras. You can find many of them like on Django packages or go on PyPy. But but that's that's one way to categorize these. Another is alerts and statuses. Some some indicators will be in your face and tell you, hey, there's a problem, and here's where I think it is. And other other times, like using the console, for instance, you can ask the system

Speaker 1: for more information Qualitative and quantitative. Sometimes indicators tell you, hey, everything is everything's good to go. And other times they'll tell you, hey, everything's good to go, but here's the specific things that you should be looking at. And then affirmative and negative. Some indicators might give you like a bright green or red light telling you, hey, this system or this thing is good to go or is not good to go. And it's the same in Django. There are tools that'll tell you, hey, everything's good or everything's not. Some examples, a car, some of the built-ins are like dials, uh gauges, dashboard lights. And then you can add things. You can go to the store and you can buy a fuse tester.

Speaker 1: You can get a uh a tire gauge, you can get a diagnostic tool. Houseplants. Again, like this, this applies to troubleshooting anything. So built-in. So the leaf color of your plant. If you stick your finger in the soil, how moist is it? And you can buy extra things like a moisture meter or a temperature sensor to give you better indications of what might be wrong and where that problem is. And the last example, my dog, Lady Duchess, one of her built-in indicators is her level of cuddliness I can troubleshoot her a little bit by telling, if she's very cuddly, then something's wrong. I love her to death, but she wants her space. And the rate of treat consumption, if she's not eating enough treats, if I'm handing it to her and she's not taking it, something is definitely wrong.

Speaker 1: But there's other things that we can add, like a GPS caller. Uh she's an escape artist, so I needed to get that And it tells me how many steps she's taken each day, how much rest she's getting, some other information. So anything in life, really anything in life, there are built-in things that you can look at, and there are things that usually can be added. It might be surprising, but these same sort of indicators and and techniques can be used with Django. So what are some of the built-ins? And again, I I know many of you are familiar with with some of these, but uh definitely want to go over them so everybody's on the same page. So template error pages, if you have your settings set to debug is true, so you're in the debug mode.

Speaker 1: And you go to a page where the template doesn't exist or there's a problem with the view or a variety of other errors, you'll get a page that looks kind of like this. It gives you the actual error message. Uh it'll tell you what Django tried to do, and it'll often give you some things to look at. Uh if you use the Django extensions uh package, you can also use uh work so that gives you a uh uh built in um opportunity to query that uh that page and and debug. Django error reporting. So if you have debug in your settings set to false , you're on a test or production system.

Speaker 1: You can set up the admins setting to email you from Django. Basically the same information that was in that template page comes to you in an email. The checks framework. If you're not familiar with this, I would encourage you to get familiar. The checks framework runs through a whole set of different checks. Static checks. As you start up your server to make sure that everything is correct. This is most of the categories that it's looking at, but there are a few others. And the cool thing about the checks framework is it goes through each of them. It'll tell you if something is like straight up an error, if it's just a warning, or if there's just some information that you should know about that check. And it's extensible.

Speaker 1: So in this example, here I've got DJ Stripe in uh installed and they've added checks To make sure that some of the settings for DJ Stripe are correct. And as you can see, there's a warning that I didn't set one of them correctly. There's some information just with some extra context to help me out. And you can see there's there's three identified total and nothing silenced. So it's a great tool. I encourage you, you know, look look at that built-in tool and extend it for your application if there's things that should be checked when you start up uh your server. The console and logging, so uh

Speaker 1: definitely check out the the the opportunity to go into the shell and um You know, request information from your Django application is useful. And logging, you can log so much information that gives you context about things in your application. incredibly helpful. Many of the commands in in Django, uh in in the Django management, uh you can increase the verbosity. I don't know if I'm saying that right, verbosity, whatever. But you can increase it. I think the standard is is uh a level of one, but you can increase it all the way to three and get very detailed information about some of those commands And then some of the things that you can add to Django. So those are all the built-ins, but what are some of the tools that might be helpful if

Speaker 1: that's not enough? Django debug toolbar is a great one. It's recommended in the Django docs , and it gives you a panel that shows you a whole variety of different things. It'll show you the time it took to build and load the page. It'll tell you. if your database database queries are taken a long time and where in that uh chain of of queries the problem might be. Like the Django Chex framework, the Django debug toolbar is something that you can extend. You can add additional panels. And there's some that are available if you go to their website, some that are available to install. Uh as third-party things, and then again you you can build your own as well.

Speaker 1: Uh performance profilers. So if you have pages that are going a little slow, This is an indicator that tells you that there is a problem. This one is is not necessarily telling you how to resolve it, but telling you that there is a problem. You can get a list of of all the different endpoints that you've uh gone to on your site and how long they're taking uh to load. And then by clicking on them you can get some details about uh that that chain of events that that may be causing the slowdown. And then error tracking and performance monitoring. Um most of these tools are uh for pay kind of things. The one I use is Sentry.

Speaker 1: I I like it, but uh I haven't used the the other ones out there so there may be um I'll show you a list of some of the others in a little bit here. I'm not chilling for Century, although I've really enjoyed their service. So when you load up their error page, you get the error message at the top, what what the actual error is. You get some some details about the event and you get the the stack trace and you can view that stack trace in their fancy format with with uh an accordion that shows you each block or you can get it raw. You can add tags, so an opportunity for you to add uh additional context, for instance, in your request.

Speaker 1: Maybe well as an example in my application, I have sort of a three-layer structure where I have the users. They all belong to either a water user account or a district, and every water user account belongs to a district. All of that to say, if I want to add context about What water user account or what district the user was logged into when this error happened in the request, I can add a tag that shows that information. You get some background information about the database calls and cache information. And just a ton of additional detail. Now, this might be if you're just beginning in Django, this might be really intimidating, but over time, once you start to learn what's available in this tool or

Speaker 1: whichever error tracking tool you're using, uh all that added context is is incredibly helpful for pinpointing problems. So here's some of the others that are out there. Just did a quick Google search recently and Rollbar, New Relic. I I think both of those have at various points been sponsors or been out in the hallway here. uh honey badger, bug snag, ray gun. There's there's several options out there. I encourage you to to look into them and find one that that works for you. Health checks is another option. So this is an example of the Django health checks package. There's there's lots of uh

Speaker 1: for pay or or external services you can use to do similar things. But the nice thing about this is it integrates really well with Django. uh and it just gives you a page so I have it at the endpoint on my on my application uh you know my URL slash health check And it just gives you a page really quickly with red or green uh check marks to tell you, hey, this thing or that thing is good or bad. Uh by default, it has uh tools for celery, for um Redis. Postgres, but you can also add your own checks really easily. It took me maybe five minutes to add one recently. They have really good documentation. Definitely check it out So that was Django Health Check.

Speaker 1: There's also Django Watchmen. I have not used it myself, but I've seen or I've heard really good things about it as well. And their their GitHub repo seems to be very healthy. Uh and then last, very simple, you can just add checks to your admin. So I recently had a an issue where I was having some weird intermittent issues with celery where uh it looked like celery was good most of the time, but the number of tasks getting processed, uh were way less than what should have been. And I didn't know when that was happening or where. So in the process of until I was able to get that troubleshot and and narrow down to a specific solution, I just

Speaker 1: through this panel into my admin that shows me uh the the current uh most recent hour 24 hours and and a week Compared to the previous hour, 24 hours and a week, how many tasks were processed through celery? It gave me a really quick indication that, hey, something's wrong now. So how do we break down problems? So we we went through some of the indicators that there may be a problem and some of the tools that'll help you identify where that problem might be. But how do you how do you break these problems down? Really, at the end of the day, a big problem i is is a bunch of smaller problems uh that are waiting to be solved. So it's important to be able to isolate the uh the variables in a in a particular problem and narrow the scope.

Speaker 1: If you're looking at a complex system, uh like a a big Django application, trying to fit all that in your in your head and and troubleshoot a problem while looking at the whole picture. Uh it's it's it's just not possible. You gotta find ways to to narrow the scope of where that problem may be. So some of the some of the ways that you can do that is really I don't want to get into anything about testing here because testing is super important. Um but but it's outside of the scope of of this talk. Nonetheless, if you're making your system testable, you're usually making uh you know your functions and methods itempotent. You're you're not putting huge blocks of code in a function or a class.

Speaker 1: You're you're you're making uh Things reasonably small that they can be tested. And just going through that process itself, making your system testable already makes it much easier to narrow down problems because you can then extract those pieces of code to to identify, hey, is the input the problem to this thing? Is the output the problem? But breaking it down to smaller components is is incredibly helpful in troubleshooting. And again, performing only one block or one one one function, one one thing in a block of code. To a reasonable extent is helpful.

Speaker 1: You don't want to get to the point where every function is a single line of code, but breaking those things down significantly instead of having long blocks. uh will will help you with with dissecting the problem. And it also makes it much easier to ask for for help, which we'll talk about later on. When you can extract that small piece of code that you think may be the problem instead of having to work with the entire uh you know module. So debugging back in the day, uh Betty Holberton, uh personal hero of mine. She worked on the ENIAC systems, and their method of troubleshooting was often literally to pull cables or pull components

Speaker 1: and figure out: hey, does the system work up to this point? And and that's a reliable way of troubleshooting that's been use for for years and years and years. Um if you can If you can break something somewhere, break the execution of something, and then see does it, does the program, does the electronics, does the whatever system get to that point successfully? It it's worked it worked for the ENIAC and it'll work today. So you can use the Python debugger for that Most IDEs , integrated developer environments, you can set a breakpoint visually in the GUI there just by clicking on the the left gutter uh for most of them

Speaker 1: and it will set a breakpoint and then when you run the program uh your IDE or or the uh uh shell will will stop at that point and give you some diagnostic information. Hey, what what do the variables in your system look like at this point now that you've broken the execution? So that's incredibly helpful again for narrowing the scope of your problem, being able to focus in a little bit. But narrowing the scope is is only part of the problem, right? You don't want to uh prematurely Narrow the scope to a particular function or a line of code thinking that that's uh the problem when it may not be. So you

Speaker 1: got to balance narrowing that scope and breaking the problem down to a smaller piece with avoiding tunnel vision. It's really easy to get fixated on something and spend hours trying to troubleshoot a small block of code that turns out not to be the problem. Sometimes you need to step back and look at the bigger picture. It's helpful to consider if you've been stuck on a problem for a long time, it's helpful to consider if you made the correct assumptions. When you started narrowing your scope down to a particular place. Was that based on on good assumptions? Uh did you miss something important that might have led you elsewhere in your program? Is the problem really what you think it is?

Speaker 1: And is the problem where you think it is And the scary one is uh what if there's more than one problem? So that's where again it's helpful to be able to break your code down into smaller blocks when you're when you're building your Django application. Because if there's more than one problem, being able to test those separately is going to be very helpful. And it also helps to get the perspective of somebody outside of your particular problem. When you've been focused on something for a long time, you you get tunnel vision, you you you may uh Benefit from getting outside help. So a problem well stated is a problem half-solved.

Speaker 1: It's a great quote. And One of the techniques for troubleshooting that is is very uh a a a very positive thing is Called rubber duck debugging. And the idea is that you explain your problem and what you think the issue is to somebody else. Ideally, if you don't have a person to explain it to, you explain it to your rubber duck Just thinking through a problem, working through it, can often point you in the right direction. Once you framed it in your mind that, hey, I think it's this because of these things, and here's why. Being able to explain that problem will get you halfway there. If you don't have a rubber duck, you can use a regionally appropriate animal,

Speaker 1: in this case a javelina for New Mexico. When to ask for help. If you're hopelessly stuck and frustrated, uh you're you're not going to get anywhere. Your stress levels increase, your thinking decreases. not a great opportunity for for finding a problem and solving it. Uh if you want new perspectives, sometimes there's a problem that you you can probably get to, but Having some some uh additional perspectives and insights on similar problems from somebody who's dealt with that stuff before could be helpful. And sometimes you just need a fresh pair of eyes. We we all get uh you know tired and and frustrated. Having somebody else look at it can be helpful.

Speaker 1: Asking questions isn't a sign of failure. It's a skill. Uh and it's it's something that you You may have to work to get better at. Framing a problem so that somebody else understands it is not always an easy thing. You need to provide context. So you've got to be able to explain the problem clearly, how it started, what were the initial symptoms, how did you even identify that this was a problem? what what variables are involved. You gotta be specific so it helps to share snippets of code. Don't assume that the problem is obvious to other people. Somebody else may be really smart, but but with just walking into your particular problem,

Speaker 1: They may never have dealt with that thing before. They may still be able to help you, but but you got to give them some background and some context. And then be open to suggestions and feedback. Sometimes people will suggest things to try. that might seem weird or outside of your experience, don't just discard other people's recommendations out of hand without a good reason. It's important to be able to provide a minimum reproducible example or MRE. There's other similar terms for this, but the idea is you know a a a a small problem that that another person can take and run and help you out really quickly. They shouldn't have to download your entire git repo to help you solve a tiny problem, for instance.

Speaker 1: People really want to help you. They even want to do it for free, but none of us likes having our time wasted. None of us likes feeling like somebody doesn't care enough. to to put in the effort to get our help. So I encourage you know think through think through your your examples that you're providing when you're asking for help. And give them the whole context. So a bad example, if you go on a form somewhere and say I'm using Django and I want to upload a file, I've created a model and a form, but I get errors when I try to upload a file. You're probably not going to get any help. You know, what what version of Django or Python are you using? What specific error messages are you getting? What does the code look like?

Speaker 1: Did you expect some behavior that you didn't get? And probably most importantly, what so far have you tried? What steps have you taken? Just answering that last one can go a long way towards convincing other people that you're worth uh you know trying to help that you've put in some effort to this problem, you've gotten stuck, and now you're asking for help. So consider how it looks to somebody who's never seen your particular project before. And what would you need if you were in their shoes trying to help you? Another uh or better example of that same one, so uh here they're saying the specific version of Django they're using, what they're trying to do.

Speaker 1: They created a model , the form isn't shown, and then given an example of the relevant code. So look, there's some models, some forms. We can see in their view that they've got a context variable form that they're sending to the template. And then there's their template. And oh no. They used forms instead of form as their template variable. Really quickly, we can identify what the problem is and help them out. That's a very simplified example, but uh hopefully it helps to frame you know adding the context that that other folks need, whether it's online or or in a conversation about how They can help you solve a problem.

Speaker 1: Another quick example: my view is not working. I'm trying to create a view that will display all the objects, but it doesn't work. And here's a chunk of code. But what does doesn't work mean? That that might be an error. That might be something that you're seeing in the browser. What error messages are you getting? So uh if you've got like a stack trace, that's helpful. Uh if you get that that uh template uh error page. You know, pasting the relevant information from that into a Stack Overflow or Reddit or Django Forum page can be helpful to give some of that additional context. What does the code look look like? What were you expecting when when you did this thing? And again, what have you tried so far?

Speaker 1: So, a better example of that is here. I'm trying to create a view that'll display a list of all the objects in a model. I'm getting a 500 error. I'm not sure why. Here's the error message I'm getting. Here's my code. You know, providing more information to people as long as it's relevant to your problem is incredibly helpful for them to be able to help you. Where can you get help when it comes to to Django when you're running into problems? So the Using Django section of the Django forum is is really an amazing place. Uh and I don't I don't think Ken is in here, but if if y'all don't uh thank Ken Whitesol and and give him some praise

Speaker 1: I don't think the Django Forum would maybe even exist if it weren't for that guy. He's incredibly prolific on there answering questions from across the community. The Django ticket tracker, if you think that the problem you have is not necessarily in your application, but maybe in Django itself It can help to look at the ticket tracker. It can be a little intimidating when you first go on there. The search is is uh has some some very complex options. Um But but you can go on there and you can often get background information about maybe why a decision was made that led to the problem that you're seeing. You can see if other people have had similar problems. It's a good resource. Social media, many of the people in this room and in this conference are on Mastodon.

Speaker 1: Some are on the other place as well. It's well worth looking into. LinkedIn is is an option. I've talked to a few people today even that are on LinkedIn. I'm not a personal fan, but but it's there. It's an option and there are people that want to help you there as well. Uh the Django and Django Learning subreddits, if you're on Reddit, they they often have a lot of really good information and people willing to help. Stack overflow, of course. There's lots of Django related tags for any any particular package or aspect of Django. Uh and then the Discord and IRC channels, um, although if you work through a problem, if you're troubleshooting something and you get to a solution, I would encourage you to take whatever you put on the Discord or IRC

Speaker 1: and write maybe a Today I Learned uh blog post or something. Those Those two in particular are very ephemeral, and you learn something, it'd be a shame if you're the only one who ever benefits from that because nobody ever sees that feed again. Put put that information about how you solved the problem, what it was, put it out there for the world so other people can benefit. And then documenting the process. And I think this is one where I haven't been good all the time about, and I think many of us are not, but just like I was saying, you know, documenting the process helps not only you. Uh, you know, in the future if you run into the same problem or a similar problem again, but it helps other people to learn from your process of troubleshooting.

Speaker 1: Write it down. So if you're writing like a blog post or if you're just writing a log for yourself, it can be really helpful to think through what exactly was the problem. What were the steps that you that you tried? How did you break that problem down? Why? That's a big one. If you made a change somewhere, if you tweak something and and Again, this doesn't just apply to Django. Uh when it comes to documenting troubleshooting on like your Jeep, if if you have a Jeep. or your plumbing system, writing down why you made a change, why you turned it up, why you adjusted a voltage, why you did a thing. Is a huge piece of the context to understanding where your troubleshooting process went. What did you expect to see when you made whatever change you made?

Speaker 1: What was the actual outcome? And what else might you try? So a lot of times when we're troubleshooting really big, complex problems You may not be able to sit down and work through that whole process in one sitting. You know, you may have meetings. You may have to leave work for the day and come back tomorrow. So writing down What what else you were thinking when you stopped? What else you were thinking you might check later on for for people like me with a very short-term memory that That's a lifesaver because if I if I think about something, hey, I should check this, and then I get up and go somewhere, I'm never never gonna think about that that potential uh step again So in review , understand and use the indicators and tools that are available to you.

Speaker 1: There's there's a rich set of indicators and tools that can help you identify that there's a problem, figure out where that problem is, and help you to solve that problem. Break your problems down into reasonable uh chunks so that you can uh test those separately or share that that chunk of code with somebody else. Uh Avoid tunnel vision, so don't get so focused in on a particular problem for a long period of time. Make sure you're you're stepping back and looking at the bigger picture. Ask for help effectively. Again, I I'm I'm on online all the time, uh, you know, answering posts on Reddit, answering posts here and there. People love to help. I'm sure almost everybody in this room probably likes to help other people work through things.

Speaker 1: But nobody likes it when when somebody's asking for help and not helping themselves to to get that solved. And then document things. Sometimes it's as easy as you know when if you're using Git, for instance, adding additional comments in your commit about what you did and why can help you later on. The more effectively you troubleshoot, the better you're gonna become at it. I just want you all to remember like when it comes to troubleshooting, it's There are things that you can do to make yourself better. And I think a lot of times we we don't think formally through that process or formally think about what tools and techniques are available to us.

Speaker 1: So there's uh my information if you're ever interested in contacting me. Um and finally, my pup again. Thank you very much. I appreciate y'all coming.

Speaker 2: Um before Jack leaves, is there any question? We have one more minute for a question. Okay, I have a question for you. So what are your day-to-day tools that you always have in all your projects that are constantly moving around with? For debugging or troubleshooting?

Speaker 1: Uh Django debug toolbar is a a really great one. Uh if you're using uh Ajax or HTMX. It's it's not always as effective for for those sorts of transitions where the page isn't changing. Um but but for For most applications, it's an incredible tool. I really like Sentry, as I mentioned. And again, there's several other similar tools that provide you information, but having Having a huge amount of context about a particular problem I find really helpful. So those are probably my two favorites, one being a built-in or a package that you can install and one being an external service.

Speaker 2: Awesome. Round of applause for Jack, please.