WEBVTT 1 00:00:05.599 --> 00:00:08.759 Hey, everybody, and welcome to another episode of the Ruby 2 00:00:08.839 --> 00:00:09.640 Rops podcast. 3 00:00:09.839 --> 00:00:12.640 This week, on our panel we have John Eperson. 4 00:00:12.839 --> 00:00:15.839 Hello, everybody up stutters Hey. 5 00:00:16.000 --> 00:00:19.519 I'm Charles Maxwood from devchat dot TV working on stuff 6 00:00:19.519 --> 00:00:21.399 over at Most Valuable dot dev. 7 00:00:21.440 --> 00:00:23.719 So go check that out. We have a special guest 8 00:00:23.760 --> 00:00:28.199 this week, and that is Chelsea Troy. Chelsea, how's it going. 9 00:00:28.480 --> 00:00:30.440 Hey, it's going well. How about you? 10 00:00:30.719 --> 00:00:32.880 We're doing great. You want to introduce yourself real quick? 11 00:00:33.359 --> 00:00:36.399 Sure? Yeah, my name is Chelsea Troy. I am a 12 00:00:36.439 --> 00:00:40.520 software engineer. By day. I work on a couple of 13 00:00:40.520 --> 00:00:43.880 different projects that focus on projects that are saving the 14 00:00:43.920 --> 00:00:48.960 planet or advancing basic scientific research, or providing resources to 15 00:00:49.359 --> 00:00:53.520 underserved communities. And then in the evenings, I teach a 16 00:00:53.520 --> 00:00:57.079 class called Mobile Software Development at the University of Chicago 17 00:00:57.159 --> 00:01:01.359 in their master's programming Computer Science, and or, I don't know, 18 00:01:01.479 --> 00:01:03.920 organize a couple of conferences here in Chicago when we're 19 00:01:04.079 --> 00:01:08.280 allowed to have conferences, which is, you know, not not 20 00:01:08.519 --> 00:01:10.879 right now. So I spend a lot of time lately 21 00:01:11.280 --> 00:01:13.840 taking walks and going on bike rides because we only 22 00:01:13.879 --> 00:01:16.959 get one hundred nice days in the city of Chicago. 23 00:01:17.200 --> 00:01:19.599 So nice have you had a heat wave out there 24 00:01:19.680 --> 00:01:20.640 like we've had out here. 25 00:01:21.159 --> 00:01:24.959 So it's funny you ask. Last week was relatively warm, 26 00:01:25.000 --> 00:01:27.879 but this week it has been it's not going to 27 00:01:27.879 --> 00:01:30.120 get back to seventy degrees until the weekend. It's been 28 00:01:30.120 --> 00:01:33.480 in the sixties, which is really nice for being outside, 29 00:01:33.560 --> 00:01:35.439 with the exception of the fact that it's been raining 30 00:01:35.480 --> 00:01:38.079 cats and dogs for a lot of that. And so 31 00:01:39.120 --> 00:01:43.879 I mean people, the people enjoy the temperate weather so 32 00:01:43.959 --> 00:01:45.799 much that they just go out in it any way 33 00:01:45.799 --> 00:01:49.519 with their umbrellas and raincoats. But I like a cloudy 34 00:01:49.599 --> 00:01:53.359 day without the rain when I can get it nice. Yeah. 35 00:01:53.400 --> 00:01:57.560 Well, the topic that I have on our on our 36 00:01:57.599 --> 00:02:02.120 calendar is practical debugg and it looks like you've given 37 00:02:02.159 --> 00:02:04.959 some talks on this. I found a blog post about 38 00:02:04.959 --> 00:02:08.560 it on chelseatroy dot com. I'm a little curious as 39 00:02:08.599 --> 00:02:13.759 we get going, what is your approach to debugging, because 40 00:02:14.240 --> 00:02:15.919 it seems like a lot of people just kind of 41 00:02:16.000 --> 00:02:18.840 go and tweak the code until it works. 42 00:02:19.479 --> 00:02:19.719 Well. 43 00:02:20.759 --> 00:02:25.759 Yeah, so I guess the way that debug really does 44 00:02:25.800 --> 00:02:29.159 depend on the situation. But one of the things that 45 00:02:29.240 --> 00:02:31.199 I have noticed in the way that we teach people 46 00:02:31.199 --> 00:02:35.039 to program is that we leave out certain skills when 47 00:02:35.240 --> 00:02:38.199 we are educating folks, and that is in part by 48 00:02:38.240 --> 00:02:40.800 danta of the resources that we make available and in 49 00:02:40.840 --> 00:02:43.199 part by dint of what we think of as programming 50 00:02:43.680 --> 00:02:46.560 as opposed to what I find that it really is, 51 00:02:46.560 --> 00:02:49.319 at least in my case. So the vast majority of 52 00:02:49.319 --> 00:02:51.960 the tutorials online and even the majority of the courses 53 00:02:51.960 --> 00:02:55.560 that you'll see undergraduate graduate institutions, Udacity, you name it, 54 00:02:55.919 --> 00:02:57.840 they're focused on teaching people how to do things. And 55 00:02:57.879 --> 00:03:00.360 the vast majority of the tutorials that are available are 56 00:03:01.000 --> 00:03:04.120 developer has already practiced how to do this several times, 57 00:03:04.159 --> 00:03:06.800 so they get it right on the tutorial, and then 58 00:03:06.840 --> 00:03:09.400 they go through the tutorial getting it right. They don't 59 00:03:09.479 --> 00:03:11.400 run into issues, or they don't run into a lot 60 00:03:11.479 --> 00:03:13.599 of issues. They certainly don't run into the number of 61 00:03:13.639 --> 00:03:17.240 issues that you would actually run into implementing something for 62 00:03:17.280 --> 00:03:19.520 the first time. And that's for a number of reasons. 63 00:03:19.520 --> 00:03:22.080 They want the tutorial to focus on how to do something. 64 00:03:22.520 --> 00:03:26.240 They want the tutorial to be a relatively smooth experience 65 00:03:26.319 --> 00:03:29.280 for people, which is good and it absolutely has its place. 66 00:03:30.120 --> 00:03:32.400 One of the things that I think that we undervalue 67 00:03:32.960 --> 00:03:38.280 in our programming education is all of the skills around 68 00:03:38.360 --> 00:03:40.439 that that we end up picking up over time. So 69 00:03:40.680 --> 00:03:45.280 relatively experienced developer might have an easier time debugging than 70 00:03:45.319 --> 00:03:48.199 a relatively new one. But right now, the way that 71 00:03:48.240 --> 00:03:51.199 we have it set up, the vast majority of people's 72 00:03:51.199 --> 00:03:55.520 intuition and skill around debugging has to come from essentially 73 00:03:55.560 --> 00:03:59.680 inductive reasoning from all of the situations that they personally 74 00:04:00.120 --> 00:04:02.919 have encountered in their career. Because we don't have a 75 00:04:02.960 --> 00:04:06.159 pedagogy around debugging, We don't have a praxis around debugging. 76 00:04:06.400 --> 00:04:08.400 We just sort of like figure it out from all 77 00:04:08.400 --> 00:04:12.199 of our individual experiences. Now, for that same reason, we 78 00:04:12.280 --> 00:04:15.759 don't see particularly good translation between debugging on one stack 79 00:04:15.800 --> 00:04:19.360 and debugging on another stack. Take an extremely experienced Rubius 80 00:04:19.560 --> 00:04:23.439 or extremely experienced Rails developer and they'll be absolutely excellent 81 00:04:23.560 --> 00:04:26.360 debugging in Rails. Put them on a mobile stack and 82 00:04:26.399 --> 00:04:27.920 they're going to have a lot more trouble than you 83 00:04:27.920 --> 00:04:29.959 would expect based on the amount of experience that they 84 00:04:29.959 --> 00:04:34.199 have in Rails, because there isn't a generalized practice for debugging, 85 00:04:34.279 --> 00:04:37.920 and so a lot of people's quote unquote debugging skill 86 00:04:38.160 --> 00:04:42.000 comes from I have seen literally this exact bug before, 87 00:04:42.319 --> 00:04:45.720 as opposed to I have seen bugs like this before, 88 00:04:45.839 --> 00:04:48.079 and I know what might be causing it, or I 89 00:04:48.120 --> 00:04:50.680 have some intuition about how to narrow down what might 90 00:04:50.680 --> 00:04:53.079 be causing it, and so we end up with these 91 00:04:53.759 --> 00:05:01.160 extremely specific, extremely personal, experienced based debug ugging strategies like 92 00:05:01.199 --> 00:05:03.279 you're talking about, where people just kind of mess around 93 00:05:03.319 --> 00:05:05.879 with things until it works, and the more experienced they 94 00:05:05.879 --> 00:05:08.399 have with a particular stack, the more they'll be able 95 00:05:08.399 --> 00:05:10.560 to hone in on what to mess around with. But 96 00:05:10.560 --> 00:05:12.759 then when they switch stacks, they lose a lot of that. 97 00:05:12.839 --> 00:05:14.199 And I think that a lot of that can be 98 00:05:14.319 --> 00:05:19.160 solved by taking a more deliberate approach to the way 99 00:05:19.160 --> 00:05:22.360 that we debug and the way that we teach debugging, 100 00:05:22.519 --> 00:05:26.079 because the vast majority of the time that we spend 101 00:05:26.079 --> 00:05:30.560 as programmers isn't usually on cranking through solutions where we 102 00:05:30.639 --> 00:05:33.000 already know what we're going to end up with at 103 00:05:33.000 --> 00:05:35.680 the end, and in the situations where we are doing that, 104 00:05:35.720 --> 00:05:37.720 where we're cranking a whole bunch of code, we know 105 00:05:37.800 --> 00:05:40.040 exactly how it's going to work, a lot of times 106 00:05:40.040 --> 00:05:42.920 developers think of that as rote they don't really like it. 107 00:05:43.160 --> 00:05:45.000 What they want to do is they want to approach 108 00:05:45.079 --> 00:05:48.199 new challenges and when we're approaching new challenges, we're spending 109 00:05:48.240 --> 00:05:51.040 more than half of our development time looking at something 110 00:05:51.079 --> 00:05:53.079 that's not working the way that we were expecting it 111 00:05:53.120 --> 00:05:56.680 to work, and needing to figure out why it's not 112 00:05:56.759 --> 00:05:59.279 working the way we expect it to work and how 113 00:05:59.360 --> 00:06:01.959 to get it to work. And because we don't model that, 114 00:06:02.399 --> 00:06:07.040 because we don't teach that, folks assume that a quote 115 00:06:07.120 --> 00:06:10.079 unquote good developer spends less time doing that than they 116 00:06:10.079 --> 00:06:14.519 actually do because we don't see it modeled anywhere, and they, 117 00:06:14.879 --> 00:06:18.240 in addition, spend more time doing that then they might 118 00:06:18.360 --> 00:06:20.920 need to if they had a strategy for going in 119 00:06:20.959 --> 00:06:23.720 and debugging something in a general sense, Does that make sense? 120 00:06:24.040 --> 00:06:25.000 Yeah, that makes sense to me. 121 00:06:25.319 --> 00:06:28.040 I'm one of the people that, Yeah, I just want 122 00:06:28.079 --> 00:06:31.759 to make it work right, and so if I can 123 00:06:31.800 --> 00:06:36.160 shortcut even a well reasoned approach, I'm gonna try it. 124 00:06:37.040 --> 00:06:40.959 Yeah. It's it's it's a tough it's a tough intuition 125 00:06:41.079 --> 00:06:43.920 to fight, and I think that there's a reason for that. 126 00:06:44.639 --> 00:06:48.360 I think that we think about programming as being single 127 00:06:48.439 --> 00:06:50.720 modal when there's actually two modes to it. So the 128 00:06:50.720 --> 00:06:53.800 first one we might think of as like building mode 129 00:06:53.879 --> 00:06:57.079 or productivity mode. This is mostly what we see modeled, 130 00:06:57.399 --> 00:06:59.519 This is mostly what we see in tutorials, and this 131 00:06:59.600 --> 00:07:02.199 is most what we're striving for. This is also what 132 00:07:02.199 --> 00:07:05.079 we reward software engineers for. If we see them spending 133 00:07:05.120 --> 00:07:07.920 a lot of time in this like cranking building mode, 134 00:07:07.959 --> 00:07:10.680 we think of them as a good software engineer. And 135 00:07:10.839 --> 00:07:14.839 in that mode, we're focused on getting something working fast. 136 00:07:15.000 --> 00:07:19.079 Our focus is on creating something that wasn't there before, 137 00:07:19.600 --> 00:07:23.240 and speed is of the essence in this mode. So 138 00:07:23.279 --> 00:07:26.959 the problem comes in that that mode is most effective 139 00:07:27.199 --> 00:07:31.120 when we understand what our code is doing. In a case, 140 00:07:31.160 --> 00:07:32.800 we're we're facing a bug, or in a case we' 141 00:07:32.800 --> 00:07:36.199 we're facing an issue in our code. By definition, we 142 00:07:36.240 --> 00:07:39.040 don't quite understand what our code is doing, because if 143 00:07:39.040 --> 00:07:41.160 we did understand what our code was doing, it wouldn't 144 00:07:41.160 --> 00:07:42.920 be doing the thing that we don't want it to do. 145 00:07:43.600 --> 00:07:46.920 So the base assumption that makes the building mode work 146 00:07:47.040 --> 00:07:50.000 is no longer true. But we continue to try this 147 00:07:50.079 --> 00:07:52.759 building mode. We continue to move as if speed is 148 00:07:52.759 --> 00:07:55.040 of the essence. Is if the focus is on getting 149 00:07:55.079 --> 00:07:58.639 something to happen, and it doesn't end up working particularly well, 150 00:07:58.639 --> 00:08:01.240 and it works worse and worse, Yes, the less we 151 00:08:01.399 --> 00:08:05.519 understand exactly what our code is doing. Because speed relies 152 00:08:05.759 --> 00:08:10.000 on making quick judgments. Speed relies on heuristics that relies 153 00:08:10.040 --> 00:08:13.800 on assumptions, and when our assumptions are correct, then we 154 00:08:13.839 --> 00:08:15.800 can move faster. But if we don't understand what our 155 00:08:15.839 --> 00:08:20.079 code is doing, there's some assumption that we're making that's incorrect, 156 00:08:20.120 --> 00:08:22.000 and the faster we try to move, the more likely 157 00:08:22.079 --> 00:08:25.240 it is that we gloss over that assumption that we 158 00:08:25.319 --> 00:08:27.839 don't take the time to re examine that assumption. So 159 00:08:27.920 --> 00:08:30.720 the faster we try to move, the lower the likelihood 160 00:08:30.720 --> 00:08:32.159 that we're going to be able to end up catching 161 00:08:32.200 --> 00:08:34.879 it insidious bug because we're not re examining those assumptions 162 00:08:34.879 --> 00:08:37.919 that we're making. So there's really a second mode that 163 00:08:37.960 --> 00:08:39.720 we need to be aware of in programming, and it's 164 00:08:39.720 --> 00:08:41.840 something that we need to switch into when we don't 165 00:08:41.919 --> 00:08:44.159 understand what our code is doing. We need to be 166 00:08:44.200 --> 00:08:47.799 able to switch from that building mode into an investigative 167 00:08:47.840 --> 00:08:50.440 mode where we're no longer focused on creating something that 168 00:08:50.480 --> 00:08:54.240 once upon a time wasn't and now instead we're focused 169 00:08:54.360 --> 00:08:58.639 on understanding exactly what our code is doing, but maybe 170 00:08:58.679 --> 00:09:02.840 more importantly, understand our assumptions about what our code is 171 00:09:02.879 --> 00:09:06.799 doing because somewhere in those assumptions something isn't matching up. 172 00:09:07.320 --> 00:09:11.840 That's our opportunity to slow down, to compare what our 173 00:09:11.879 --> 00:09:13.919 code is doing to what it is that we think 174 00:09:14.000 --> 00:09:17.720 our code should be doing, and narrow down the location 175 00:09:18.000 --> 00:09:21.600 in the code where the difference is happening so that 176 00:09:21.639 --> 00:09:24.200 we can then fix it and bring our assumptions and 177 00:09:24.240 --> 00:09:27.200 the codes function back into line to resolve the issue. 178 00:09:27.559 --> 00:09:31.559 So slow down, huh, go ahead? Yeah, So you you 179 00:09:32.240 --> 00:09:32.600 all right? 180 00:09:32.879 --> 00:09:35.759 So talking about these modes since since we got here, 181 00:09:35.799 --> 00:09:39.679 because I think this is super interesting and it's it 182 00:09:39.759 --> 00:09:41.919 appears that you have thought quite a bit about this, 183 00:09:42.000 --> 00:09:43.919 because you're super eloquent at talking about it. 184 00:09:44.159 --> 00:09:44.840 Huh, thank you. 185 00:09:44.879 --> 00:09:46.799 I appreciate that there's a lot. 186 00:09:46.960 --> 00:09:48.679 So there's a lot of language here, and I think 187 00:09:48.720 --> 00:09:51.120 I think I vaguely understand what's going on. Hopefully I 188 00:09:51.200 --> 00:09:53.360 understand it's slightly better than that. How do you teach 189 00:09:53.399 --> 00:09:57.440 this to somebody? Because as I was sitting here listening 190 00:09:57.480 --> 00:10:01.639 to you talking like, okay, yes, I recognize eyes where over. 191 00:10:01.720 --> 00:10:04.519 I mean, I've been doing this for almost fifteen years, 192 00:10:04.559 --> 00:10:07.080 so at some point, hopefully I've gotten sort of good 193 00:10:07.080 --> 00:10:10.600 at this, right, and I feel like I have stumbled 194 00:10:10.639 --> 00:10:13.720 my way through sort of having these two modes, right, 195 00:10:14.080 --> 00:10:17.320 or at least I can look back on my past 196 00:10:17.440 --> 00:10:19.360 and like kind of feel like I recognize that. 197 00:10:20.159 --> 00:10:21.639 And as I. 198 00:10:21.600 --> 00:10:24.440 Think about like people that I'm mentoring, this is this 199 00:10:24.519 --> 00:10:26.559 is kind of the frame that I'm thinking about right now. 200 00:10:27.159 --> 00:10:31.200 This is definitely a stumbling block, right. So, for example, 201 00:10:31.360 --> 00:10:34.840 I have one person that I'm mentor right now that 202 00:10:35.240 --> 00:10:39.039 they're always in build mode every week, and I'm spending 203 00:10:39.279 --> 00:10:43.200 all all this time and energy trying to get this 204 00:10:43.240 --> 00:10:47.159 person to slow down, right, So, like, are there ways 205 00:10:47.519 --> 00:10:48.399 do you have tips? 206 00:10:48.440 --> 00:10:50.480 Maybe you don't. Maybe you're just like, look. 207 00:10:50.279 --> 00:10:53.080 I'm just talking about what we should do, not necessarily 208 00:10:53.080 --> 00:10:55.159 how we get there, right, And that's fine, But I'm 209 00:10:55.159 --> 00:10:58.000 curious if you have tips, how do you convey this 210 00:10:58.120 --> 00:11:02.279 to somebody? Hey, look like here's the value of slowing down. 211 00:11:02.679 --> 00:11:05.120 Maybe here's a framework for when you choose to slow 212 00:11:05.159 --> 00:11:08.159 down and when you know, flip back to build mode. 213 00:11:08.360 --> 00:11:11.080 I know there's a lot of weird questions in there. 214 00:11:12.159 --> 00:11:13.000 Look what you want up? 215 00:11:13.600 --> 00:11:16.120 Yeah, no, it makes sense to me. I think that 216 00:11:16.879 --> 00:11:20.000 you're right. So one of the things that we need 217 00:11:20.080 --> 00:11:24.639 to be able to identify in practice is when do 218 00:11:24.679 --> 00:11:30.120 we need to shift between these two modes? What signals 219 00:11:30.159 --> 00:11:32.440 can we use to determine that we should be in 220 00:11:32.679 --> 00:11:37.240 a building mode versus an investigative mode. And so one 221 00:11:37.320 --> 00:11:40.440 of the things that I use for this is so 222 00:11:40.480 --> 00:11:42.720 there are a couple of different strategies that we can 223 00:11:42.799 --> 00:11:47.120 use for debugging, right, and there's one in particular that 224 00:11:47.200 --> 00:11:51.399 tends to show up really really commonly when we are 225 00:11:51.480 --> 00:11:55.080 in when we are in build mode, because it is 226 00:11:55.120 --> 00:11:59.399 effective for build mode. So I call it the standard strategy. 227 00:12:00.000 --> 00:12:04.039 And what this is is that when you run into 228 00:12:04.080 --> 00:12:06.840 a bug, you try changing the thing that you think 229 00:12:06.879 --> 00:12:09.960 is most likely to be causing the bug, and you 230 00:12:10.000 --> 00:12:12.919 see if it works or not. If it doesn't work, 231 00:12:13.240 --> 00:12:15.600 you try changing the thing you think is second most 232 00:12:15.720 --> 00:12:18.679 likely to be causing the bug, and hopefully that works. 233 00:12:19.039 --> 00:12:20.840 And if it doesn't work, then you try changing the 234 00:12:20.879 --> 00:12:23.000 thing that you think is the third most likely to 235 00:12:23.039 --> 00:12:27.919 be causing the bug. This is perhaps the fastest kind 236 00:12:27.960 --> 00:12:33.000 of shortcut strategy to get something working when you understand 237 00:12:33.039 --> 00:12:35.799 what's happening in your code, Because when you do understand 238 00:12:35.840 --> 00:12:37.519 what's happening in your code, the thing that you try 239 00:12:37.559 --> 00:12:39.519 first is in fact the most likely thing to be 240 00:12:39.519 --> 00:12:41.799 causing the bug, and you get through it relatively quickly. 241 00:12:42.279 --> 00:12:44.440 That's not going to be the case with insidious bugs. 242 00:12:44.440 --> 00:12:45.840 So that's not going to be the case with a 243 00:12:45.879 --> 00:12:50.000 bug where you're making an assumption that's fundamentally inaccurate to 244 00:12:50.039 --> 00:12:52.440 what it is that the code is doing, because the 245 00:12:52.519 --> 00:12:54.159 things that you think are the most likely to be 246 00:12:54.200 --> 00:12:57.639 causing the bug are like in line with your assumptions 247 00:12:57.639 --> 00:13:01.919 about what the code is doing. So standard strategy great 248 00:13:01.960 --> 00:13:05.080 for build mode. Here's where it falls down is that 249 00:13:05.159 --> 00:13:07.320 if you don't understand what's happening in your code, you 250 00:13:07.320 --> 00:13:09.320 can end up in this kind of vicious cycle with 251 00:13:09.360 --> 00:13:13.360 the standard strategy where, for example, you try changing the 252 00:13:13.399 --> 00:13:15.399 thing you think is most likely to be causing the bug, 253 00:13:15.960 --> 00:13:19.120 and it doesn't work. So you try the changing the 254 00:13:19.159 --> 00:13:21.000 thing you think is second most likely to be causing 255 00:13:21.000 --> 00:13:24.200 the bug, and it still doesn't work. So you run 256 00:13:24.240 --> 00:13:26.919 out of ideas, and then you get pissed and you 257 00:13:26.960 --> 00:13:28.679 go back and you try changing the thing that you 258 00:13:28.759 --> 00:13:30.679 tried the first time to see if it works this 259 00:13:30.799 --> 00:13:33.159 time around, and you get in this kind of like 260 00:13:33.279 --> 00:13:37.399 vicious cycle with it. Right, that's the failure mode for 261 00:13:37.440 --> 00:13:41.639 the standard strategy. That's where build mode fails us when 262 00:13:41.639 --> 00:13:44.799 we don't understand what's going on with our code, And 263 00:13:44.960 --> 00:13:47.480 that I think is a really strong signal when you're 264 00:13:47.519 --> 00:13:51.320 going back and trying the thing again that you already 265 00:13:51.399 --> 00:13:54.399 tried and saw it didn't work. Yeah, sometimes that works. 266 00:13:54.600 --> 00:13:56.559 Maybe that's what it was. There was some configures you 267 00:13:56.720 --> 00:13:59.960 or something like that. If it doesn't work the second 268 00:14:00.080 --> 00:14:03.159 in time, I think that's your like really strong signal 269 00:14:03.200 --> 00:14:05.879 that it's time to switch into investigation mode. Because at 270 00:14:05.919 --> 00:14:09.799 that point, clearly you've made some assumptions. Something somewhere is 271 00:14:09.840 --> 00:14:13.480 not matching up. So then if the standard strategy is 272 00:14:13.480 --> 00:14:15.519 not going to work for us, we have to have 273 00:14:15.559 --> 00:14:18.360 strategies that we could use instead. Right, there's got to 274 00:14:18.399 --> 00:14:21.799 be something other than the standard strategy. Figure out, you know, 275 00:14:22.399 --> 00:14:26.159 instead of focusing on getting the thing working as quickly 276 00:14:26.200 --> 00:14:29.960 as possible, we can instead pick a strategy that focus 277 00:14:30.000 --> 00:14:34.000 is on something else. So the strategies that I use 278 00:14:34.080 --> 00:14:37.919 at that point both focus on there's two, I'll go 279 00:14:38.039 --> 00:14:41.159 over them, but they both they shift the focus from 280 00:14:41.159 --> 00:14:43.519 how do I get this thing working to how do 281 00:14:43.639 --> 00:14:48.799 I identify the place where my assumptions about what's happening do 282 00:14:49.000 --> 00:14:53.000 not match up with the code and what it's doing right. 283 00:14:53.440 --> 00:14:56.600 So there are a couple. One of them I try 284 00:14:56.639 --> 00:14:58.759 to use. One of them is helpful for speed in 285 00:14:58.759 --> 00:15:01.200 some cases, when it's not possible, I use the other one. 286 00:15:01.519 --> 00:15:04.679 So the first one which I can use for speed 287 00:15:05.440 --> 00:15:08.200 is I call it the binary search strategy. And basically 288 00:15:08.200 --> 00:15:10.600 the way that this works is that I identify some 289 00:15:10.759 --> 00:15:15.240 point where the code begins executing right and identify some 290 00:15:15.320 --> 00:15:18.120 point either where the code finishes or at which point 291 00:15:18.159 --> 00:15:20.240 I'm positive the bug has happened. So I have these 292 00:15:20.279 --> 00:15:23.399 beginning and end points right now. I try to pick 293 00:15:23.480 --> 00:15:26.879 some spot in between those two, kind of in the middle, 294 00:15:27.120 --> 00:15:29.759 and at that point I use a breakpoint, or I 295 00:15:29.840 --> 00:15:32.559 use print statements or any of a number of tactics 296 00:15:32.559 --> 00:15:36.039 to get into the code and test that all of 297 00:15:36.080 --> 00:15:40.240 the assumptions that I am making at that point are correct. 298 00:15:40.759 --> 00:15:43.840 So I'm printing out variables determining what the flow of 299 00:15:43.879 --> 00:15:46.559 the execution is. And suppose I test all of my 300 00:15:46.600 --> 00:15:49.120 assumptions at that point in the code and whatever i'm 301 00:15:49.159 --> 00:15:53.960 printing logging breakpoint and everything's working is expected. If everything's 302 00:15:53.960 --> 00:15:57.559 working is expected at that point, then I pick a 303 00:15:57.600 --> 00:16:01.919 point halfway between there and wherever my code finished executing 304 00:16:02.039 --> 00:16:05.000 or the bug happens. And so one of the things 305 00:16:05.039 --> 00:16:09.919 that we know from executing binary executing binary search in 306 00:16:10.440 --> 00:16:14.200 computer programs is that it's pretty fast. You can narrow 307 00:16:14.320 --> 00:16:19.000 down in relatively few steps from a really wide range 308 00:16:19.000 --> 00:16:21.679 of options what could be going on, even if you've 309 00:16:21.720 --> 00:16:23.600 got tons and tons of code in the middle. We're 310 00:16:23.600 --> 00:16:27.639 talking about in a really complicated system using binary search 311 00:16:27.679 --> 00:16:33.120 strategy five six steps maybe, which is sounds like a 312 00:16:33.159 --> 00:16:37.919 lot until you consider that you might try like fourteen fifteen, sixteen, 313 00:16:38.000 --> 00:16:41.399 twenty twenty five different things in a really complex system 314 00:16:41.440 --> 00:16:43.720 if you're just trying to move straight to getting the 315 00:16:43.759 --> 00:16:44.200 thing working. 316 00:16:45.480 --> 00:16:48.159 So I just want to point out, with your standard strategy, 317 00:16:48.279 --> 00:16:50.320 I'm a little bit weirded out. 318 00:16:50.159 --> 00:16:52.080 That you've been watching me code all these years. 319 00:16:54.879 --> 00:16:56.879 You know what the problem is. I've been watching me 320 00:16:57.039 --> 00:17:02.519 code all these years, and I do that constant, you know, 321 00:17:02.720 --> 00:17:04.599 the like maybe there was a ghost in the system 322 00:17:04.640 --> 00:17:06.160 the first time. Let me try it a second time. 323 00:17:06.160 --> 00:17:08.200 See if the ghost is gone. I've definitely done it. 324 00:17:08.240 --> 00:17:09.519 I think everybody's done it, you know. 325 00:17:10.359 --> 00:17:13.519 Yeah, but what you're saying makes sense as far as 326 00:17:13.559 --> 00:17:16.720 the binary search strategy, it's the same idea as a 327 00:17:16.759 --> 00:17:19.359 binary search tree. And I'm assuming that you got the 328 00:17:19.400 --> 00:17:23.839 idea from some structure like that. But yeah, you know, 329 00:17:24.039 --> 00:17:26.279 I mean we talk about big O and everybody makes 330 00:17:26.279 --> 00:17:28.160 a big deal out of it as an interview question. 331 00:17:28.279 --> 00:17:33.480 But I mean, yeah, you here, it actually is a 332 00:17:33.519 --> 00:17:37.519 measure of speed, right, because it's log of then you know, 333 00:17:37.680 --> 00:17:40.480 number of lines in the area you've identified as where 334 00:17:40.519 --> 00:17:44.440 the bug may be occurring, so you know, And and 335 00:17:44.480 --> 00:17:47.039 the fact that you can pick chunks of the code 336 00:17:47.160 --> 00:17:51.480 instead of you know, specific locations within the code allows 337 00:17:51.519 --> 00:17:53.400 you to narrow down well, it's either this chunk or 338 00:17:53.400 --> 00:17:57.599 that chunk, and so you know, you might have to 339 00:17:57.839 --> 00:18:01.960 log in, yeah, you know, to narrow it down. Yeah, 340 00:18:02.039 --> 00:18:07.119 instead of you know, essentially you're just doing a random selection. Yeah, 341 00:18:07.240 --> 00:18:09.920 you know, it's an informed random selection, but it's still 342 00:18:10.039 --> 00:18:13.240 random ish and hoping that you hit the right thing, 343 00:18:13.279 --> 00:18:15.640 because it's not just that you change it in the 344 00:18:15.720 --> 00:18:16.359 right place. 345 00:18:16.119 --> 00:18:17.839 But you have to change it the right way too. 346 00:18:18.319 --> 00:18:22.519 Right, Yeah, it's absolutely the case. So yeah, I love 347 00:18:22.599 --> 00:18:25.400 using the binary search strategy for that. I think I 348 00:18:25.480 --> 00:18:29.799 started using it for that after I was using get bisect, 349 00:18:30.440 --> 00:18:34.319 which essentially allows you to similarly use a binary search 350 00:18:34.359 --> 00:18:37.200 strategy to narrow down what commits something went wrong in 351 00:18:37.839 --> 00:18:40.279 and what I you know, I sort of like knew 352 00:18:40.319 --> 00:18:45.720 this cerebrally from having studied computer science, but using get bisect, 353 00:18:45.759 --> 00:18:50.240 I realized, like, it takes me, you know, a lot 354 00:18:50.440 --> 00:18:54.359 fewer steps, let's say, six ish steps to figure out 355 00:18:54.359 --> 00:18:58.119 what's going wrong, like which commit out of a hundred 356 00:18:58.279 --> 00:19:03.079 commits something wrong. One hundred commit sounds daunting at first, 357 00:19:03.079 --> 00:19:06.200 but seven steps doesn't sound nearly as daunting, and so 358 00:19:06.720 --> 00:19:10.039 this strategy could also be applied there. Now the downfall 359 00:19:10.119 --> 00:19:14.160 of this strategy it's graver speed, but it's sort of assumed. 360 00:19:14.200 --> 00:19:16.640 It works best when you're talking about like a single 361 00:19:16.759 --> 00:19:20.640 threaded application or a situation where you don't have multiple 362 00:19:20.640 --> 00:19:24.200 processes where things can break off, where the order is deterministic, 363 00:19:24.640 --> 00:19:27.079 and so when you're dealing with multiple threads or some 364 00:19:27.160 --> 00:19:31.200 other kind of nondeterministic order type of situation, the binary 365 00:19:31.279 --> 00:19:33.559 search strategy can be tough to use because you don't 366 00:19:33.559 --> 00:19:36.480 necessarily know from beginning to end of execution, like what 367 00:19:36.559 --> 00:19:39.119 the order is to do that. What you do know 368 00:19:39.759 --> 00:19:42.759 is that you start somewhere, and then at some point 369 00:19:42.759 --> 00:19:44.920 at the end something went wrong, and all this stuff 370 00:19:44.920 --> 00:19:47.799 that happened in here, whatever order it happened in, something 371 00:19:47.839 --> 00:19:51.279 went wrong. So in those cases I have to back 372 00:19:51.359 --> 00:19:56.160 up and use potentially a slower, less flashy, less cool strategy, 373 00:19:56.400 --> 00:19:58.640 which is essentially to start at the beginning of execution 374 00:19:59.559 --> 00:20:02.839 and and like at the very beginning of execution, do 375 00:20:02.920 --> 00:20:06.960 the same thing, print, log, breakpoint, test my assumptions and 376 00:20:07.279 --> 00:20:11.680 if they're wrong, then maybe that's where my issue is 377 00:20:11.680 --> 00:20:14.359 getting cost and if not, then move a little later 378 00:20:14.400 --> 00:20:18.400 in the execute basically follow the code path through, which 379 00:20:18.559 --> 00:20:23.000 feels really slow because especially if we do it like 380 00:20:23.039 --> 00:20:25.240 we start at the very beginning, all our assumptions are right. 381 00:20:25.720 --> 00:20:28.400 We start one step down, all of our assumptions are right. 382 00:20:28.759 --> 00:20:31.240 We go to two steps down, all of our assumptions 383 00:20:31.279 --> 00:20:33.720 are right. Okay, this is getting boring. When do I 384 00:20:33.759 --> 00:20:36.000 get to skip ahead and then we get to step three? 385 00:20:37.000 --> 00:20:39.480 Oh wait a minute, I was assuming I was just 386 00:20:39.519 --> 00:20:43.319 skipping to step eight and all of this time, and 387 00:20:43.359 --> 00:20:47.039 the problem was in step three. So suppose that there 388 00:20:47.039 --> 00:20:50.440 are like fifteen steps there. That sounds like a lot. 389 00:20:50.480 --> 00:20:52.400 But if your problem is in step three or step 390 00:20:52.440 --> 00:20:54.720 four or step five, you only have to try as 391 00:20:54.720 --> 00:20:57.000 many until you figure out what the actual problem is, 392 00:20:57.039 --> 00:20:59.440 which at most is going to be fifteen, Whereas if 393 00:20:59.440 --> 00:21:02.440 you're trying the same thing a million times at step eight, 394 00:21:02.559 --> 00:21:05.039 that ends up still being more steps. Even though this 395 00:21:05.160 --> 00:21:09.960 process feels really slow because kind of again by definition, 396 00:21:10.079 --> 00:21:13.640 like we don't know what's wrong, so it makes sense 397 00:21:13.720 --> 00:21:18.079 to figure out. It makes sense to systematically figure out 398 00:21:18.119 --> 00:21:21.759 what's wrong. The other really nice thing about that strategy, 399 00:21:21.839 --> 00:21:26.640 or both strategies, really is that we can feel like 400 00:21:26.680 --> 00:21:29.160 we're making progress on a bug even if we haven't 401 00:21:29.200 --> 00:21:32.759