Speaker 1: Hey, everybody, and welcome to another episode of the Ruby
Speaker 1: Rops podcast.
Speaker 2: This week, on our panel we have John Eperson.
Speaker 3: Hello, everybody up stutters Hey.
Speaker 1: I'm Charles Maxwood from devchat dot TV working on stuff
Speaker 1: over at Most Valuable dot dev.
Speaker 2: So go check that out. We have a special guest
Speaker 2: this week, and that is Chelsea Troy. Chelsea, how's it going.
Speaker 4: Hey, it's going well. How about you?
Speaker 3: We're doing great. You want to introduce yourself real quick?
Speaker 4: Sure? Yeah, my name is Chelsea Troy. I am a
Speaker 4: software engineer. By day. I work on a couple of
Speaker 4: different projects that focus on projects that are saving the
Speaker 4: planet or advancing basic scientific research, or providing resources to
Speaker 4: underserved communities. And then in the evenings, I teach a
Speaker 4: class called Mobile Software Development at the University of Chicago
Speaker 4: in their master's programming Computer Science, and or, I don't know,
Speaker 4: organize a couple of conferences here in Chicago when we're
Speaker 4: allowed to have conferences, which is, you know, not not
Speaker 4: right now. So I spend a lot of time lately
Speaker 4: taking walks and going on bike rides because we only
Speaker 4: get one hundred nice days in the city of Chicago.
Speaker 1: So nice have you had a heat wave out there
Speaker 1: like we've had out here.
Speaker 4: So it's funny you ask. Last week was relatively warm,
Speaker 4: but this week it has been it's not going to
Speaker 4: get back to seventy degrees until the weekend. It's been
Speaker 4: in the sixties, which is really nice for being outside,
Speaker 4: with the exception of the fact that it's been raining
Speaker 4: cats and dogs for a lot of that. And so
Speaker 4: I mean people, the people enjoy the temperate weather so
Speaker 4: much that they just go out in it any way
Speaker 4: with their umbrellas and raincoats. But I like a cloudy
Speaker 4: day without the rain when I can get it nice. Yeah.
Speaker 1: Well, the topic that I have on our on our
Speaker 1: calendar is practical debugg and it looks like you've given
Speaker 1: some talks on this. I found a blog post about
Speaker 1: it on chelseatroy dot com. I'm a little curious as
Speaker 1: we get going, what is your approach to debugging, because
Speaker 1: it seems like a lot of people just kind of
Speaker 1: go and tweak the code until it works.
Speaker 5: Well.
Speaker 4: Yeah, so I guess the way that debug really does
Speaker 4: depend on the situation. But one of the things that
Speaker 4: I have noticed in the way that we teach people
Speaker 4: to program is that we leave out certain skills when
Speaker 4: we are educating folks, and that is in part by
Speaker 4: danta of the resources that we make available and in
Speaker 4: part by dint of what we think of as programming
Speaker 4: as opposed to what I find that it really is,
Speaker 4: at least in my case. So the vast majority of
Speaker 4: the tutorials online and even the majority of the courses
Speaker 4: that you'll see undergraduate graduate institutions, Udacity, you name it,
Speaker 4: they're focused on teaching people how to do things. And
Speaker 4: the vast majority of the tutorials that are available are
Speaker 4: developer has already practiced how to do this several times,
Speaker 4: so they get it right on the tutorial, and then
Speaker 4: they go through the tutorial getting it right. They don't
Speaker 4: run into issues, or they don't run into a lot
Speaker 4: of issues. They certainly don't run into the number of
Speaker 4: issues that you would actually run into implementing something for
Speaker 4: the first time. And that's for a number of reasons.
Speaker 4: They want the tutorial to focus on how to do something.
Speaker 4: They want the tutorial to be a relatively smooth experience
Speaker 4: for people, which is good and it absolutely has its place.
Speaker 4: One of the things that I think that we undervalue
Speaker 4: in our programming education is all of the skills around
Speaker 4: that that we end up picking up over time. So
Speaker 4: relatively experienced developer might have an easier time debugging than
Speaker 4: a relatively new one. But right now, the way that
Speaker 4: we have it set up, the vast majority of people's
Speaker 4: intuition and skill around debugging has to come from essentially
Speaker 4: inductive reasoning from all of the situations that they personally
Speaker 4: have encountered in their career. Because we don't have a
Speaker 4: pedagogy around debugging, We don't have a praxis around debugging.
Speaker 4: We just sort of like figure it out from all
Speaker 4: of our individual experiences. Now, for that same reason, we
Speaker 4: don't see particularly good translation between debugging on one stack
Speaker 4: and debugging on another stack. Take an extremely experienced Rubius
Speaker 4: or extremely experienced Rails developer and they'll be absolutely excellent
Speaker 4: debugging in Rails. Put them on a mobile stack and
Speaker 4: they're going to have a lot more trouble than you
Speaker 4: would expect based on the amount of experience that they
Speaker 4: have in Rails, because there isn't a generalized practice for debugging,
Speaker 4: and so a lot of people's quote unquote debugging skill
Speaker 4: comes from I have seen literally this exact bug before,
Speaker 4: as opposed to I have seen bugs like this before,
Speaker 4: and I know what might be causing it, or I
Speaker 4: have some intuition about how to narrow down what might
Speaker 4: be causing it, and so we end up with these
Speaker 4: extremely specific, extremely personal, experienced based debug ugging strategies like
Speaker 4: you're talking about, where people just kind of mess around
Speaker 4: with things until it works, and the more experienced they
Speaker 4: have with a particular stack, the more they'll be able
Speaker 4: to hone in on what to mess around with. But
Speaker 4: then when they switch stacks, they lose a lot of that.
Speaker 4: And I think that a lot of that can be
Speaker 4: solved by taking a more deliberate approach to the way
Speaker 4: that we debug and the way that we teach debugging,
Speaker 4: because the vast majority of the time that we spend
Speaker 4: as programmers isn't usually on cranking through solutions where we
Speaker 4: already know what we're going to end up with at
Speaker 4: the end, and in the situations where we are doing that,
Speaker 4: where we're cranking a whole bunch of code, we know
Speaker 4: exactly how it's going to work, a lot of times
Speaker 4: developers think of that as rote they don't really like it.
Speaker 4: What they want to do is they want to approach
Speaker 4: new challenges and when we're approaching new challenges, we're spending
Speaker 4: more than half of our development time looking at something
Speaker 4: that's not working the way that we were expecting it
Speaker 4: to work, and needing to figure out why it's not
Speaker 4: working the way we expect it to work and how
Speaker 4: to get it to work. And because we don't model that,
Speaker 4: because we don't teach that, folks assume that a quote
Speaker 4: unquote good developer spends less time doing that than they
Speaker 4: actually do because we don't see it modeled anywhere, and they,
Speaker 4: in addition, spend more time doing that then they might
Speaker 4: need to if they had a strategy for going in
Speaker 4: and debugging something in a general sense, Does that make sense?
Speaker 2: Yeah, that makes sense to me.
Speaker 1: I'm one of the people that, Yeah, I just want
Speaker 1: to make it work right, and so if I can
Speaker 1: shortcut even a well reasoned approach, I'm gonna try it.
Speaker 4: Yeah. It's it's it's a tough it's a tough intuition
Speaker 4: to fight, and I think that there's a reason for that.
Speaker 4: I think that we think about programming as being single
Speaker 4: modal when there's actually two modes to it. So the
Speaker 4: first one we might think of as like building mode
Speaker 4: or productivity mode. This is mostly what we see modeled,
Speaker 4: This is mostly what we see in tutorials, and this
Speaker 4: is most what we're striving for. This is also what
Speaker 4: we reward software engineers for. If we see them spending
Speaker 4: a lot of time in this like cranking building mode,
Speaker 4: we think of them as a good software engineer. And
Speaker 4: in that mode, we're focused on getting something working fast.
Speaker 4: Our focus is on creating something that wasn't there before,
Speaker 4: and speed is of the essence in this mode. So
Speaker 4: the problem comes in that that mode is most effective
Speaker 4: when we understand what our code is doing. In a case,
Speaker 4: we're we're facing a bug, or in a case we'
Speaker 4: we're facing an issue in our code. By definition, we
Speaker 4: don't quite understand what our code is doing, because if
Speaker 4: we did understand what our code was doing, it wouldn't
Speaker 4: be doing the thing that we don't want it to do.
Speaker 4: So the base assumption that makes the building mode work
Speaker 4: is no longer true. But we continue to try this
Speaker 4: building mode. We continue to move as if speed is
Speaker 4: of the essence. Is if the focus is on getting
Speaker 4: something to happen, and it doesn't end up working particularly well,
Speaker 4: and it works worse and worse, Yes, the less we
Speaker 4: understand exactly what our code is doing. Because speed relies
Speaker 4: on making quick judgments. Speed relies on heuristics that relies
Speaker 4: on assumptions, and when our assumptions are correct, then we
Speaker 4: can move faster. But if we don't understand what our
Speaker 4: code is doing, there's some assumption that we're making that's incorrect,
Speaker 4: and the faster we try to move, the more likely
Speaker 4: it is that we gloss over that assumption that we
Speaker 4: don't take the time to re examine that assumption. So
Speaker 4: the faster we try to move, the lower the likelihood
Speaker 4: that we're going to be able to end up catching
Speaker 4: it insidious bug because we're not re examining those assumptions
Speaker 4: that we're making. So there's really a second mode that
Speaker 4: we need to be aware of in programming, and it's
Speaker 4: something that we need to switch into when we don't
Speaker 4: understand what our code is doing. We need to be
Speaker 4: able to switch from that building mode into an investigative
Speaker 4: mode where we're no longer focused on creating something that
Speaker 4: once upon a time wasn't and now instead we're focused
Speaker 4: on understanding exactly what our code is doing, but maybe
Speaker 4: more importantly, understand our assumptions about what our code is
Speaker 4: doing because somewhere in those assumptions something isn't matching up.
Speaker 4: That's our opportunity to slow down, to compare what our
Speaker 4: code is doing to what it is that we think
Speaker 4: our code should be doing, and narrow down the location
Speaker 4: in the code where the difference is happening so that
Speaker 4: we can then fix it and bring our assumptions and
Speaker 4: the codes function back into line to resolve the issue.
Speaker 3: So slow down, huh, go ahead? Yeah, So you you
Speaker 3: all right?
Speaker 6: So talking about these modes since since we got here,
Speaker 6: because I think this is super interesting and it's it
Speaker 6: appears that you have thought quite a bit about this,
Speaker 6: because you're super eloquent at talking about it.
Speaker 4: Huh, thank you.
Speaker 3: I appreciate that there's a lot.
Speaker 6: So there's a lot of language here, and I think
Speaker 6: I think I vaguely understand what's going on. Hopefully I
Speaker 6: understand it's slightly better than that. How do you teach
Speaker 6: this to somebody? Because as I was sitting here listening
Speaker 6: to you talking like, okay, yes, I recognize eyes where over.
Speaker 6: I mean, I've been doing this for almost fifteen years,
Speaker 6: so at some point, hopefully I've gotten sort of good
Speaker 6: at this, right, and I feel like I have stumbled
Speaker 6: my way through sort of having these two modes, right,
Speaker 6: or at least I can look back on my past
Speaker 6: and like kind of feel like I recognize that.
Speaker 3: And as I.
Speaker 6: Think about like people that I'm mentoring, this is this
Speaker 6: is kind of the frame that I'm thinking about right now.
Speaker 6: This is definitely a stumbling block, right. So, for example,
Speaker 6: I have one person that I'm mentor right now that
Speaker 6: they're always in build mode every week, and I'm spending
Speaker 6: all all this time and energy trying to get this
Speaker 6: person to slow down, right, So, like, are there ways
Speaker 6: do you have tips?
Speaker 3: Maybe you don't. Maybe you're just like, look.
Speaker 6: I'm just talking about what we should do, not necessarily
Speaker 6: how we get there, right, And that's fine, But I'm
Speaker 6: curious if you have tips, how do you convey this
Speaker 6: to somebody? Hey, look like here's the value of slowing down.
Speaker 6: Maybe here's a framework for when you choose to slow
Speaker 6: down and when you know, flip back to build mode.
Speaker 3: I know there's a lot of weird questions in there.
Speaker 3: Look what you want up?
Speaker 4: Yeah, no, it makes sense to me. I think that
Speaker 4: you're right. So one of the things that we need
Speaker 4: to be able to identify in practice is when do
Speaker 4: we need to shift between these two modes? What signals
Speaker 4: can we use to determine that we should be in
Speaker 4: a building mode versus an investigative mode. And so one
Speaker 4: of the things that I use for this is so
Speaker 4: there are a couple of different strategies that we can
Speaker 4: use for debugging, right, and there's one in particular that
Speaker 4: tends to show up really really commonly when we are
Speaker 4: in when we are in build mode, because it is
Speaker 4: effective for build mode. So I call it the standard strategy.
Speaker 4: And what this is is that when you run into
Speaker 4: a bug, you try changing the thing that you think
Speaker 4: is most likely to be causing the bug, and you
Speaker 4: see if it works or not. If it doesn't work,
Speaker 4: you try changing the thing you think is second most
Speaker 4: likely to be causing the bug, and hopefully that works.
Speaker 4: And if it doesn't work, then you try changing the
Speaker 4: thing that you think is the third most likely to
Speaker 4: be causing the bug. This is perhaps the fastest kind
Speaker 4: of shortcut strategy to get something working when you understand
Speaker 4: what's happening in your code, Because when you do understand
Speaker 4: what's happening in your code, the thing that you try
Speaker 4: first is in fact the most likely thing to be
Speaker 4: causing the bug, and you get through it relatively quickly.
Speaker 4: That's not going to be the case with insidious bugs.
Speaker 4: So that's not going to be the case with a
Speaker 4: bug where you're making an assumption that's fundamentally inaccurate to
Speaker 4: what it is that the code is doing, because the
Speaker 4: things that you think are the most likely to be
Speaker 4: causing the bug are like in line with your assumptions
Speaker 4: about what the code is doing. So standard strategy great
Speaker 4: for build mode. Here's where it falls down is that
Speaker 4: if you don't understand what's happening in your code, you
Speaker 4: can end up in this kind of vicious cycle with
Speaker 4: the standard strategy where, for example, you try changing the
Speaker 4: thing you think is most likely to be causing the bug,
Speaker 4: and it doesn't work. So you try the changing the
Speaker 4: thing you think is second most likely to be causing
Speaker 4: the bug, and it still doesn't work. So you run
Speaker 4: out of ideas, and then you get pissed and you
Speaker 4: go back and you try changing the thing that you
Speaker 4: tried the first time to see if it works this
Speaker 4: time around, and you get in this kind of like
Speaker 4: vicious cycle with it. Right, that's the failure mode for
Speaker 4: the standard strategy. That's where build mode fails us when
Speaker 4: we don't understand what's going on with our code, And
Speaker 4: that I think is a really strong signal when you're
Speaker 4: going back and trying the thing again that you already
Speaker 4: tried and saw it didn't work. Yeah, sometimes that works.
Speaker 4: Maybe that's what it was. There was some configures you
Speaker 4: or something like that. If it doesn't work the second
Speaker 4: in time, I think that's your like really strong signal
Speaker 4: that it's time to switch into investigation mode. Because at
Speaker 4: that point, clearly you've made some assumptions. Something somewhere is
Speaker 4: not matching up. So then if the standard strategy is
Speaker 4: not going to work for us, we have to have
Speaker 4: strategies that we could use instead. Right, there's got to
Speaker 4: be something other than the standard strategy. Figure out, you know,
Speaker 4: instead of focusing on getting the thing working as quickly
Speaker 4: as possible, we can instead pick a strategy that focus
Speaker 4: is on something else. So the strategies that I use
Speaker 4: at that point both focus on there's two, I'll go
Speaker 4: over them, but they both they shift the focus from
Speaker 4: how do I get this thing working to how do
Speaker 4: I identify the place where my assumptions about what's happening do
Speaker 4: not match up with the code and what it's doing right.
Speaker 4: So there are a couple. One of them I try
Speaker 4: to use. One of them is helpful for speed in
Speaker 4: some cases, when it's not possible, I use the other one.
Speaker 4: So the first one which I can use for speed
Speaker 4: is I call it the binary search strategy. And basically
Speaker 4: the way that this works is that I identify some
Speaker 4: point where the code begins executing right and identify some
Speaker 4: point either where the code finishes or at which point
Speaker 4: I'm positive the bug has happened. So I have these
Speaker 4: beginning and end points right now. I try to pick
Speaker 4: some spot in between those two, kind of in the middle,
Speaker 4: and at that point I use a breakpoint, or I
Speaker 4: use print statements or any of a number of tactics
Speaker 4: to get into the code and test that all of
Speaker 4: the assumptions that I am making at that point are correct.
Speaker 4: So I'm printing out variables determining what the flow of
Speaker 4: the execution is. And suppose I test all of my
Speaker 4: assumptions at that point in the code and whatever i'm
Speaker 4: printing logging breakpoint and everything's working is expected. If everything's
Speaker 4: working is expected at that point, then I pick a
Speaker 4: point halfway between there and wherever my code finished executing
Speaker 4: or the bug happens. And so one of the things
Speaker 4: that we know from executing binary executing binary search in
Speaker 4: computer programs is that it's pretty fast. You can narrow
Speaker 4: down in relatively few steps from a really wide range
Speaker 4: of options what could be going on, even if you've
Speaker 4: got tons and tons of code in the middle. We're
Speaker 4: talking about in a really complicated system using binary search
Speaker 4: strategy five six steps maybe, which is sounds like a
Speaker 4: lot until you consider that you might try like fourteen fifteen, sixteen,
Speaker 4: twenty twenty five different things in a really complex system
Speaker 4: if you're just trying to move straight to getting the
Speaker 4: thing working.
Speaker 1: So I just want to point out, with your standard strategy,
Speaker 1: I'm a little bit weirded out.
Speaker 2: That you've been watching me code all these years.
Speaker 4: You know what the problem is. I've been watching me
Speaker 4: code all these years, and I do that constant, you know,
Speaker 4: the like maybe there was a ghost in the system
Speaker 4: the first time. Let me try it a second time.
Speaker 4: See if the ghost is gone. I've definitely done it.
Speaker 4: I think everybody's done it, you know.
Speaker 1: Yeah, but what you're saying makes sense as far as
Speaker 1: the binary search strategy, it's the same idea as a
Speaker 1: binary search tree. And I'm assuming that you got the
Speaker 1: idea from some structure like that. But yeah, you know,
Speaker 1: I mean we talk about big O and everybody makes
Speaker 1: a big deal out of it as an interview question.
Speaker 1: But I mean, yeah, you here, it actually is a
Speaker 1: measure of speed, right, because it's log of then you know,
Speaker 1: number of lines in the area you've identified as where
Speaker 1: the bug may be occurring, so you know, And and
Speaker 1: the fact that you can pick chunks of the code
Speaker 1: instead of you know, specific locations within the code allows
Speaker 1: you to narrow down well, it's either this chunk or
Speaker 1: that chunk, and so you know, you might have to
Speaker 1: log in, yeah, you know, to narrow it down. Yeah,
Speaker 1: instead of you know, essentially you're just doing a random selection. Yeah,
Speaker 1: you know, it's an informed random selection, but it's still
Speaker 1: random ish and hoping that you hit the right thing,
Speaker 1: because it's not just that you change it in the
Speaker 1: right place.
Speaker 2: But you have to change it the right way too.
Speaker 4: Right, Yeah, it's absolutely the case. So yeah, I love
Speaker 4: using the binary search strategy for that. I think I
Speaker 4: started using it for that after I was using get bisect,
Speaker 4: which essentially allows you to similarly use a binary search
Speaker 4: strategy to narrow down what commits something went wrong in
Speaker 4: and what I you know, I sort of like knew
Speaker 4: this cerebrally from having studied computer science, but using get bisect,
Speaker 4: I realized, like, it takes me, you know, a lot
Speaker 4: fewer steps, let's say, six ish steps to figure out
Speaker 4: what's going wrong, like which commit out of a hundred
Speaker 4: commits something wrong. One hundred commit sounds daunting at first,
Speaker 4: but seven steps doesn't sound nearly as daunting, and so
Speaker 4: this strategy could also be applied there. Now the downfall
Speaker 4: of this strategy it's graver speed, but it's sort of assumed.
Speaker 4: It works best when you're talking about like a single
Speaker 4: threaded application or a situation where you don't have multiple
Speaker 4: processes where things can break off, where the order is deterministic,
Speaker 4: and so when you're dealing with multiple threads or some
Speaker 4: other kind of nondeterministic order type of situation, the binary
Speaker 4: search strategy can be tough to use because you don't
Speaker 4: necessarily know from beginning to end of execution, like what
Speaker 4: the order is to do that. What you do know
Speaker 4: is that you start somewhere, and then at some point
Speaker 4: at the end something went wrong, and all this stuff
Speaker 4: that happened in here, whatever order it happened in, something
Speaker 4: went wrong. So in those cases I have to back
Speaker 4: up and use potentially a slower, less flashy, less cool strategy,
Speaker 4: which is essentially to start at the beginning of execution
Speaker 4: and and like at the very beginning of execution, do
Speaker 4: the same thing, print, log, breakpoint, test my assumptions and
Speaker 4: if they're wrong, then maybe that's where my issue is
Speaker 4: getting cost and if not, then move a little later
Speaker 4: in the execute basically follow the code path through, which
Speaker 4: feels really slow because especially if we do it like
Speaker 4: we start at the very beginning, all our assumptions are right.
Speaker 4: We start one step down, all of our assumptions are right.
Speaker 4: We go to two steps down, all of our assumptions
Speaker 4: are right. Okay, this is getting boring. When do I
Speaker 4: get to skip ahead and then we get to step three?
Speaker 4: Oh wait a minute, I was assuming I was just
Speaker 4: skipping to step eight and all of this time, and
Speaker 4: the problem was in step three. So suppose that there
Speaker 4: are like fifteen steps there. That sounds like a lot.
Speaker 4: But if your problem is in step three or step
Speaker 4: four or step five, you only have to try as
Speaker 4: many until you figure out what the actual problem is,
Speaker 4: which at most is going to be fifteen, Whereas if
Speaker 4: you're trying the same thing a million times at step eight,
Speaker 4: that ends up still being more steps. Even though this
Speaker 4: process feels really slow because kind of again by definition,
Speaker 4: like we don't know what's wrong, so it makes sense
Speaker 4: to figure out. It makes sense to systematically figure out
Speaker 4: what's wrong. The other really nice thing about that strategy,
Speaker 4: or both strategies, really is that we can feel like
Speaker 4: we're making progress on a bug even if we haven't
Speaker 4: fixed it yet, because psychologically the way it feels, well,
Speaker 4: I'm interested in y'all's thoughts on this, actually, but my
Speaker 4: feeling when I'm fixing a bug using something like the
Speaker 4: standard strategy is my first assumption didn't work. I've gotten nowhere.
Speaker 4: My second assumption didn't work. I've gotten nowhere. I feel
Speaker 4: like I've made no progress until I have finished fixing
Speaker 4: the bug, which really sucks right up until the moment
Speaker 4: where I've finished fixing the bug. Whereas if I have
Speaker 4: a systematic strategy, I could say, all right, well, I
Speaker 4: haven't fixed the bug yet, but I have narrowed down
Speaker 4: like half of the possibilities for where it could be.
Speaker 4: And I know that I've narrowed down half of the
Speaker 4: possibilities because I've quantified the possibilities and I'm moving through
Speaker 4: them with some kind of like plan as opposed to guessing.
Speaker 4: And if my guess is wrong, I don't really know
Speaker 4: how much longer I'm going to be doing this.
Speaker 6: You know, there's another downside to that Wold standard strategy too,
Speaker 6: which is if you continue the standard strategy right through
Speaker 6: the time, you're at the point when you don't know
Speaker 6: what's wrong now right, but you continue just playing guests
Speaker 6: and check. Now, all of a sudden, you probably didn't
Speaker 6: take good notes as you're doing this, and when you
Speaker 6: do finally affix it, you don't know why it now works,
Speaker 6: and so this just becomes a boogeyman that you're just
Speaker 6: like scared to go back and touch again because you're
Speaker 6: just like, well, I can't touch any of that stuff.
Speaker 3: I literally have no idea why it's working now.
Speaker 6: I mean, I have done this and I can't I
Speaker 6: can't even like tell how many times like I realized
Speaker 6: somebody else was doing this because they're like, shoot, I
Speaker 6: don't know why it's working, you.
Speaker 4: Know, yeah, we uh. I think it's really funny when
Speaker 4: people talk about how programmers, you know, oh, you know,
Speaker 4: software engineers or engineers, they're like, they're not they're not
Speaker 4: superstitious or any of that stuff. Everything's evidence based to them.
Speaker 4: And I'm like, no, definitely, no, that's not how this is. Like,
Speaker 4: the longer you work with software, the less you trust software.
Speaker 4: There's a reason for that, and it's not. Yeah, I
Speaker 4: think you know it's coming out.
Speaker 5: The other side. Personally, I feel like I feel like
Speaker 5: my code is my friend now now other people's code
Speaker 5: is the enemy. My code code I've written and no
Speaker 5: one else has touched is like a lovely, warm Blanket's
Speaker 5: like something to come home to. Uh huh. So so yeah,
Speaker 5: I do feel like there's a big difference between debugging
Speaker 5: my code and debugging other people's code.
Speaker 1: Oh absolutely, is that like other people's kids, So obviously
Speaker 1: I tell you what I feel like.
Speaker 5: The difference is is that when I'm writing something, I
Speaker 5: tend to find the bugs at the time. Yeah, so
Speaker 5: this probably isn't true, but it feels like it. I
Speaker 5: feel like I'm finding the bugs when I'm writing it.
Speaker 5: But when you've meen it happened. The other day, I
Speaker 5: was asked to come and look at the roilse five
Speaker 5: side and work out why it was being a naughty website.
Speaker 5: And if someone else's code, you know, and you've just
Speaker 5: got no no idea what's going on at all, and
Speaker 5: it just feels like a much more difficult process. And
Speaker 5: I also get a lot angrier when I'm debugging other
Speaker 5: people's code. I'm a lot more forgiving of my own code.
Speaker 5: Is there like an management approach to ducking?
Speaker 4: Oh man? So it's funny that you mentioned this because
Speaker 4: so I'm working on an implementation right now if the
Speaker 4: Raft distributed Consensus algorithm, and I'm the only person who
Speaker 4: has worked on this code, which means I got to
Speaker 4: make all my own stylistic choices about it and every
Speaker 4: you know, all the messages are like QT definitely not
Speaker 4: what the original Raft team would have had their servers do.
Speaker 4: And they're they're very nice to each other. They say
Speaker 4: please and thank you and all that stuff. It's very
Speaker 4: Canadian of them. But I I find that I like
Speaker 4: the problems in that code. The idiosyncrasies in that code
Speaker 4: are endearing to me because it's mine, you know, the
Speaker 4: same way that my frenziosyncrasies are like endearing. Whereas like
Speaker 4: if somebody else were to try to run this code,
Speaker 4: they would probably be like, this is ridiculous, Like why
Speaker 4: does it this is no, I don't like this at all,
Speaker 4: but it's fun to me. And they did this. I'm
Speaker 4: not gonna saye this correctly. I'll go back and find
Speaker 4: it and we can put it in the show notes.
Speaker 4: But they did this study about people's opinions of their
Speaker 4: own origami. Are you all familiar with this study? So
Speaker 4: essentially they taught some people how to do origami, people
Speaker 4: who were not particularly skilled at origami to begin with.
Speaker 4: And what they found was this really interesting effect where
Speaker 4: the objectively worse the finished product was, the more the
Speaker 4: creator loved it because it was an indication of how
Speaker 4: much they had struggled with the origami and then they
Speaker 4: finally got something sort of working, and that struggle was
Speaker 4: like that struggle played a role in their fondness for
Speaker 4: the finished product more than the objective judgment of the
Speaker 4: finished product. And I think that probably happens with Code two.
Speaker 5: Is say, look, what's the way this is going.
Speaker 4: Well, it's that you have context on like all of
Speaker 4: the problems that you've already solved in that code, right,
Speaker 4: And other people they don't have that. They just come
Speaker 4: in and they just assume everything that's working was always working,
Speaker 4: and they focus on the things that that don't And
Speaker 4: I think, you know, we struggle with that, and it's
Speaker 4: of course, it's when you're when you're debugging your own
Speaker 4: code to you have a little bit more intuition for
Speaker 4: what was happening, and you don't have to back translate
Speaker 4: from the code to the original intuition the way that
Speaker 4: you would with somebody else's code. And when we go
Speaker 4: in and we maintain somebody else's code. I do this
Speaker 4: a lot in my job. I find that many of
Speaker 4: the projects that I take on are relatively complex, relatively undocumented,
Speaker 4: relatively untested code basis where I'm going in and I'm
Speaker 4: adding documentation, I'm adding tests. In some cases, I'm going
Speaker 4: in and the dial developer is gone and nobody knows
Speaker 4: how it works, and I have to figure it out.
Speaker 4: And in that case, we're not just talking about debugging.
Speaker 4: We're not even at debugging yet. We're starting at like
Speaker 4: forensic software analysis. Effectively, we have to be able to
Speaker 4: go in and like CSI this code and figure out
Speaker 4: from clues like what's what's going on? What's going on
Speaker 4: in there, and figure out you know, based on like
Speaker 4: these indicators in the code. I think originally this piece
Speaker 4: of it was supposed to do this, And that's a
Speaker 4: whole separate skill set from debugging, which is also you know,
Speaker 4: forensic software analysis is a fun thing to get good
Speaker 4: at too. But once again, like debugging, if we're not
Speaker 4: if we're not promoting that to a first class skill set,
Speaker 4: if we're not recognizing it and teaching it as a
Speaker 4: first class skill set, it just feels to people like
Speaker 4: either wasted time or like an indication that they're not
Speaker 4: good at their jobs. And it's not that they're not
Speaker 4: good at their jobs. It's that this is a skill
Speaker 4: that takes time, and the fact that you need to
Speaker 4: take time to do this thing doesn't mean you're bad.
Speaker 4: It means that this is one of the things we
Speaker 4: have to take time to do when we're doing this job.
Speaker 4: The same way that a cowboy, you know, it's not
Speaker 4: just about riding. You also have to be able to
Speaker 4: saddle up your horse. You have to be able to
Speaker 4: feed your horse. You have to have cattle sense or
Speaker 4: whatever it is they have. You have to be able
Speaker 4: to cook your beans and a can on the fire.
Speaker 4: You know, you've got to be able to do all
Speaker 4: this stuff that's not just riding your horse, right, and
Speaker 4: it's not wasted time to do all those things. It's
Speaker 4: stuff you gotta do to be, you know, a cattle person.
Speaker 4: And I think it's the same with debugging, forensic software analysis.
Speaker 4: We've got these skills that we need that we don't
Speaker 4: factor into our mental model of what it means to
Speaker 4: be a good programmer, and we really should.
Speaker 5: Can I ask you about reproduction?
Speaker 4: Sure?
Speaker 3: Because what's your question?
Speaker 4: So when a man in a one and love each
Speaker 4: other very much, I'm so.
Speaker 5: Glad you picked that up. The hardest bit I have is,
Speaker 5: especially in Rudy because there's so much rails floating around,
Speaker 5: is reproducing the expletive expletive bug. Because a lot of
Speaker 5: the stuff I do is kind of an e commerce
Speaker 5: site and you get the people with phoning up and
Speaker 5: they said, your website had just done that, and then
Speaker 5: the client phones me up and I said, like they say,
Speaker 5: once or twice a day, the website does this right,
Speaker 5: And for most people it's fine, but it's those edge
Speaker 5: cases where you're hitting a bug which can't be easily reproduced,
Speaker 5: and often once you have reproduction on that bug, solving
Speaker 5: it's just like the easiest thing ever, it's just getting
Speaker 5: it to do it again. Is there any tips for
Speaker 5: getting it to do it again?
Speaker 4: Ah, that's a good question, because that can be a
Speaker 4: really tough one. You know, it be hard to replicate
Speaker 4: the exact environment that it happened, in the exact state
Speaker 4: of the database, that it happened in the exact like
Speaker 4: whatever the configuration is it's going on. We know with
Speaker 4: bugs that are tough to reproduce that if we're not
Speaker 4: able to get it to reproduce, there's some aspect of
Speaker 4: the configuration that is outside of the environment that we're
Speaker 4: currently modeling that is different from what the person who
Speaker 4: saw the bug originally provided. And I think there's kind
Speaker 4: of two parts to this. The first one is recognizing
Speaker 4: which aspects of the environment are missing from our understanding,
Speaker 4: And this one is tough, but it's the one between
Speaker 4: the two that I think software engineers have a little
Speaker 4: more success with than the other one because the other one,
Speaker 4: and this is an ongoing struggle is figuring out how
Speaker 4: to get the details of the entire environment to be
Speaker 4: able to replicate it one hundred percent, Because when somebody
Speaker 4: phones in and they say, like, my app just did this,
Speaker 4: it's not necessarily it's not necessarily true that that person
Speaker 4: has access to the details of the entire environment where
Speaker 4: the problem is cropping up, or that they're even like
Speaker 4: aware of all of the environmental variables it might be
Speaker 4: causing the issue. And so in those cases it can
Speaker 4: be really really tough, and sometimes the solution ends up
Speaker 4: being all right. So it happens once or twice a day.
Speaker 4: We take all of the issues of this type and
Speaker 4: we put them in a bucket and suppose that it happens.
Speaker 4: So we get two of them one day, two of
Speaker 4: them the next day, and two of them the next day.
Speaker 4: So at what point does this bucket have enough data
Speaker 4: points in it that we can go through and systematically
Speaker 4: compare it to all of the times when this works
Speaker 4: correctly that aren't in this bucket? What environment variables do
Speaker 4: we think could be different between those two situations? And so, unfortunately,
Speaker 4: I think sometimes we got to like wait and figure
Speaker 4: out from this collection of individual instances what might be
Speaker 4: different about the individual instances from the way that like
Speaker 4: normal circumstances operate, we see some so there are there
Speaker 4: may be some valuable transfer here between techniques that medical
Speaker 4: researchers use for diagnosing and understanding rare conditions. Is that
Speaker 4: you just don't have that many people who have it happen.
Speaker 4: But in order to get solid research on a condition,
Speaker 4: you have to sort of have a minimum sample size,
Speaker 4: And so what they'll do is they'll try to create
Speaker 4: a record of everybody who has this condition and hopefully
Speaker 4: get the sample size up to you know, twenty fifty
Speaker 4: one hundred something where they can start using some aggregate
Speaker 4: and analysis techniques to figure out what the difference might be.
Speaker 4: But I think sometimes with rare bugs, we, like I said,
Speaker 4: it's tough, and if it's not happening all the time,
Speaker 4: it can be difficult. But sometimes we're not where it's
Speaker 4: tough in the first place, and we're making it tougher
Speaker 4: on ourselves by not taking that systematic step. Either. We
Speaker 4: don't have a record of all the times this rare
Speaker 4: bug happens so that we can start to implement some
Speaker 4: aggregate analysis when it's happened twenty times fifty times, one
Speaker 4: hundred times, and we can tell customers in the meantime, like,
Speaker 4: you know, we know this is a really thorny issue.
Speaker 4: We're not really sure why it's happening. We're in the
Speaker 4: process of data collection right now to see if we
Speaker 4: can figure out why it's happening, and on the back
Speaker 4: end be collecting that somewhere so that we know when
Speaker 4: we get to some certain number that we think like
Speaker 4: we can try again and try to do some aggregate
Speaker 4: analysis on this. Then we'll set aside time we'll put
Speaker 4: in we'll put a ticket in the system for when
Speaker 4: we get twenty examples of this, we'll go back and
Speaker 4: take a look at this in the aggregate as opposed
Speaker 4: to each individual time it's happening, attempt to like debugget
Speaker 4: based on that single instance without looking at any of
Speaker 4: the instances in the past we have. This is a
Speaker 4: little bit unrelated, so I promise we'll come back to
Speaker 4: the actual subject of debugging. But we see a similar
Speaker 4: tendency in organizational dynamics and teams on software teams, where
Speaker 4: like if somebody's demonstrating a pattern of behavior of like
Speaker 4: mild microaggressions or like one little bitty thing that's like
Speaker 4: not really worth addressing on its own. Sometimes those situations
Speaker 4: can be insidious because in any given situation, it's like
Speaker 4: not worth bringing up. But over time, this person demonstrates
Speaker 4: a pattern of doing this, and we don't you we
Speaker 4: don't have any like aggregate strategies for saying, you know,
Speaker 4: there's this teeny little thing. There are these teeny microaggressions
Speaker 4: and any given one of them might be a mistake,
Speaker 4: but it's happening like regularly over the course of you,
Speaker 4: and so it's a pattern that we need to address.
Speaker 4: I found that it can be really helpful in organizations
Speaker 4: as well too. Somehow, even if we're not addressing those
Speaker 4: things when they happen, keep some kind of record of them,
Speaker 4: and then address the pattern when it's clear that it's
Speaker 4: a pattern, because at that point it's no longer about
Speaker 4: like whatever the latest incident is, which wasn't that big
Speaker 4: a deal. It's about the fact that the individual incidents,
Speaker 4: though not a big deal, individually aggregate to form a
Speaker 4: pattern that is, you know, ever so slightly dragging on
Speaker 4: our team, ever so slightly increasing our turnover, our churn
Speaker 4: on who leaves the company, and it's it's a cost
Speaker 4: that over time we can't afford, but it's tough to
Speaker 4: address at individual instances. So I think there is there
Speaker 4: is a parallel there. But I know we're not talking
Speaker 4: about organizational dynamics. We're talking about bugs. So I'm happy
Speaker 4: to come back to the code side of people.
Speaker 5: Have bugs in their personality and they need to be fixed.
Speaker 5: Oh yeah, absolutely one place where we have a solution
Speaker 5: for this.
Speaker 6: Right, So a clock, Your clock gets off by a
Speaker 6: little bit like every moment, right, But you don't go
Speaker 6: to your clock every two minutes to go fix it
Speaker 6: by like the tiny milliseconds that it's off. You do
Speaker 6: it like once or twice a year maybe or something
Speaker 6: like that. Right, So we sort of this is the
Speaker 6: same thing.
Speaker 3: Right. You set up a system that.
Speaker 6: You can check in or whatever it is, right like,
Speaker 6: but you have to design a system around it. Like
Speaker 6: it's not something that you can You can't let it
Speaker 6: go because otherwise your clock doesn't work anymore.
Speaker 3: But you also can't check it every moment. You have
Speaker 3: to come up with some system that works for you.
Speaker 3: I feel like it's kind of like the time boxing thing.
Speaker 6: Like everybody that I mentor I like teach to timebox
Speaker 6: and they're like, well, how long do I timebox for?
Speaker 3: And I'm just like, that's actually a personal thing. You
Speaker 3: just kind of say you just kind of figure it
Speaker 3: out for you. Like I have my own time boxes
Speaker 3: that work for me.
Speaker 6: I tend to break my days down into like half
Speaker 6: days more or less, just because that works really well
Speaker 6: for me. Like, you know, I eat lunch, there's like
Speaker 6: a natural break, and because I'm like ADHD and I'll
Speaker 6: like get super hyper focused on something like that, I
Speaker 6: always come up for air to half day, so I
Speaker 6: can guarantee that I can at least time box for that.
Speaker 3: You know, it's all sort of the same thing.
Speaker 6: But my point is like you have to design the
Speaker 6: system getting back to the subject or whatever, and I
Speaker 6: don't feel like you're saying something different. I feel like
Speaker 6: it's going to be a personal thing kind of thing here.
Speaker 4: Yeah, I would say so. I think. So this conversation
Speaker 4: is making me wonder whether Century and similar error logging
Speaker 4: platforms have a way for you to like automatically put
Speaker 4: certain types of bugs in buckets and then like alert
Speaker 4: you when the bucket has a certain number of issues
Speaker 4: in it or something.
Speaker 3: I know that some of them let you bucket.
Speaker 6: Right, So if I have like the same kind kind
Speaker 6: of book, happen again, it like buckets it together. It says, hey,
Speaker 6: here's an instance, here's you know, here's a list of
Speaker 6: ten instances that have happened.
Speaker 3: I don't know.
Speaker 6: I don't know if there's an alert. I mean I
Speaker 6: can make it. I've used like three or four of them,
Speaker 6: and I can. I mean, they usually give you an
Speaker 6: option to like give you a daily briefing or something
Speaker 6: like that.
Speaker 4: But right, like I know that Sentry has a button
Speaker 4: that allows you to just mass ignore a certain type
Speaker 4: of error. So I wonder if there's the opposite, you know, like,
Speaker 4: if there are enough of these, tell me.
Speaker 6: Should we should discuss mass ignoring errors? Because that's a
Speaker 6: that's a ignore. Like leaving the beeping signal on all
Speaker 6: the time is also a problem.
Speaker 3: Right, so you just put.
Speaker 4: Electrical tape over the check engine light. I don't need
Speaker 4: to know about this.
Speaker 3: That means when you really do have a problem, you
Speaker 3: have no idea.
Speaker 4: That's absolutely true. So this is something that I've run
Speaker 4: into a fair amount with end to end to SUN
Speaker 4: mobile applications, is like, and part of this is that
Speaker 4: sometimes the end to end frameworks are like a little
Speaker 4: flaky at their core. I get yet, that's absolutely true,
Speaker 4: but the signal to noise ratio is like low enough
Speaker 4: that sometimes developers start completely ignoring their end to end
Speaker 4: test to the point that they don't even look at
Speaker 4: why it's failing. And at some point the reason it's
Speaker 4: failing like sneakily changes, but people don't notice because they
Speaker 4: just see it fail and they're like, oh, that test
Speaker 4: always fails. And then a few months later something was
Speaker 4: wrong in the app for months. Oh, we didn't realize
Speaker 4: this was wrong. Why didn't we realize it was wrong?
Speaker 4: Or in the best case, somebody goes in and they
Speaker 4: actually take a look at the end to end test
Speaker 4: and they're like, wait a second, wait a second, it's
Speaker 4: actually pointing out an issue. This isn't just flakiness, it's
Speaker 4: like actually a problem.
Speaker 3: Oh my gosh.
Speaker 6: So Andrew Mason, who actually used to be on the show,
Speaker 6: so I chat with him every week, and he was
Speaker 6: just discussing this exact similar to the problem last week,
Speaker 6: right like, and he was he was trying to deal
Speaker 6: with the code base, where like it was just failing. Sorry,
Speaker 6: I'm totally about to say an opinion here, so it
Speaker 6: could be controversial. But he was like, well, you know
Speaker 6: which test do I delete? And I was like, dude,
Speaker 6: I was like, if your test suite is failing, it's
Speaker 6: providing zero value right now.
Speaker 3: I was like, start.
Speaker 6: Commenting stuff out until it's green, because a test week
Speaker 6: provides zero value until it's green. And you were talking
Speaker 6: about like, I mean, I've been at places before where
Speaker 6: they let let these tests go like all the time,
Speaker 6: where they just rerun their test feet like four times
Speaker 6: till it passes, right, But that flaky test is telling
Speaker 6: you something sometimes anyway.
Speaker 3: So my point is like I'm a.
Speaker 6: Big believer in deleting and deleting like broken flashy lights.
Speaker 3: All right, I'm done.
Speaker 4: How do you feel about coming back to flaky test
Speaker 4: on some kind of regular interval, similar to like coming
Speaker 4: back to rare bugs on a regular interval and try
Speaker 4: like time boxing, attempting to fix it.
Speaker 3: I think that's the same thing.
Speaker 6: But I'm not really a big believer in Okay, So
Speaker 6: I worked pretty hard and self discipline for myself, right,
Speaker 6: and you know I have friends and I trust their
Speaker 6: self discipline to a point.
Speaker 3: But as far as like trusting like a.
Speaker 6: General random developer that I don't know to like come
Speaker 6: back to a thing at a regular interval.
Speaker 3: I have almost zero trust for that.
Speaker 6: So so my answer is I just deleted instead, because
Speaker 6: because I don't trust the other guy. I guess kind
Speaker 6: of like kind of like lou Katese the other guy's code.
Speaker 5: Oh man, it happens more as you get older.
Speaker 4: Oh really, the trust goes down.
Speaker 5: I used to believe in other people's code. Then I
Speaker 5: started working on Brailles.
Speaker 4: Oh Man. So a friend of mine, hill O Wayne.
Speaker 4: He also keeps a software engineering blog, and in one
Speaker 4: of his posts, he's talking about Uncle Bob and Uncle
Speaker 4: Bob's approach to software resilience, and he in talking about
Speaker 4: that approach, he points out that parts of the approach
Speaker 4: rely almost entirely on telling developers to be more disciplined,
Speaker 4: and that you can't that doesn't like discipline as the
Speaker 4: solution for making something not happen is never going to
Speaker 4: make that thing not happen because you can't just get
Speaker 4: an entire population to all exercise discipline to the threshold
Speaker 4: that you would like them to coach. Your bugs, guys,
Speaker 4: the better programmers, what is your problem?
Speaker 3: Then you don't have to do bug.
Speaker 5: So Uncle Bob was saying we should be more disciplined,
Speaker 5: and you're saying that's not possible.
Speaker 4: Well, what I'm saying is that you're uh, not that
Speaker 4: it's not possible to be more disciplined, but rather that
Speaker 4: it's not possible to command a bunch of people to
Speaker 4: be disciplined and then guarantee that that's going to work.
Speaker 3: Right. Can't use it to validate your personal problems.
Speaker 5: Unfortunately, that sounds that sounds like do you want to share?
Speaker 3: John?
Speaker 4: No.
Speaker 3: I actually was just saying that, like, you can't.
Speaker 6: You can't use the excuse of like, oh I can't
Speaker 6: be more disciplined because they said it on review Rooks.
Speaker 4: Oh man? Oh if people always take everything that we
Speaker 4: say on here as ironclad advice, And there are a
Speaker 4: few statements from earlier that I need to protect.
Speaker 5: But that's a sign of a good podcast that you
Speaker 5: wish you'd never done it?
Speaker 4: Oh man?
Speaker 3: Is it?
Speaker 4: I will say that for myself. Part of the reason
Speaker 4: I use automated testing is precisely because I do not
Speaker 4: trust my own discipline, because you know, there are certain
Speaker 4: circumstances where now, let me go ahead and say that
Speaker 4: I think unit TDD is very valuable in certain circumstances.
Speaker 4: I also don't see UNIT TDD as a panacea for
Speaker 4: software verification. I think there are other methods that we
Speaker 4: can use in addition, and I happen to also think
Speaker 4: some of those other methods are better suited to certain
Speaker 4: problems that UNIT TDD doesn't address. However, However, one nice
Speaker 4: thing about unit test driven development is that if I
Speaker 4: write the test first, then I code for the API
Speaker 4: that I want as a reader of the code, which
Speaker 4: is good because code gets read many multiples of the
Speaker 4: number of times it gets written, and so I can
Speaker 4: be lazy at the point where I'm writing the test
Speaker 4: and write for the API that I want. Then when
Speaker 4: I'm writing the actual code, I'm held accountable for an
Speaker 4: API that's relatively easy to read, as opposed to starting
Speaker 4: with an API that's relatively easy to write, which ends
Speaker 4: up being harder to read, which causes more strife over
Speaker 4: the course of the life of the code base. And
Speaker 4: that works precisely because I do not trust myself to
Speaker 4: go the extra mile and make the easy to read
Speaker 4: API without the accountability step of the test in the front,
Speaker 4: and I imagine that my code would be harder to
Speaker 4: read if I weren't using that where I can to
Speaker 4: make and to hold myself accountable to that API. So
Speaker 4: it's a perfect example of using a system precisely because
Speaker 4: I don't trust my own discipline. I can't. I cannot
Speaker 4: rely on discipline, even in the one person system of myself,
Speaker 4: to make things work the way that I ultimately, like
Speaker 4: theoretically want them to work, because in the short term
Speaker 4: it's harder for me.
Speaker 3: Yeah.
Speaker 1: Well, the other reason that I do a lot of
Speaker 1: that is just that, I mean, going back to the
Speaker 1: assumptions on how things work, I'm not going to remember
Speaker 1: that next week. I mean honestly, people are like, well
Speaker 1: if I come back to it in six months, I'm like,
Speaker 1: if I come back to it in six days, right,
Speaker 1: And so, you know, by having some of these disciplines
Speaker 1: it you know, just speaking to the larger idea here, right, Yeah,
Speaker 1: if I can encode my assumptions, if I can make
Speaker 1: sure that the things that I care about are things
Speaker 1: that I am checking on, that's where it makes sense.
Speaker 2: Mmm.
Speaker 4: What's the adage? The more you cuss about a line
Speaker 4: of code and how inscrutable it is, the more likely
Speaker 4: it becomes that you wrote it.
Speaker 2: That is so true, get blamed. Ah crap, yep, yep.
Speaker 1: And then the other half of the time it's well,
Speaker 1: look John did it. And then you go and you
Speaker 1: look at that commit and he ran the Linter and
Speaker 1: it changed the indentation. I actually put the code on
Speaker 1: that line.
Speaker 5: Anyway, I've got a theory that Linter's and making thugs
Speaker 5: harder to find. Oh, because back in the day it
Speaker 5: used to be able to side channel do a side
Speaker 5: channel attack on nice cote basis where if you found
Speaker 5: like different indentation and non standard formatting and stuff. I
Speaker 5: just kind of zero into that. You go, ah, this
Speaker 5: person can't be bothered to put a space before the
Speaker 5: curly brakes, so the chances are they're a total loser.
Speaker 5: But now, and this is where the bug is, I'm like,
Speaker 5: you know, if it looks if it looks all over
Speaker 5: the place, then I'm like, ah, there'll be bugs here.
Speaker 5: And I just found this was really helpful for assessing
Speaker 5: code qualities. Can they can be bothered to indent properly,
Speaker 5: But now with Linter's and the Rubo cop and everything,
Speaker 5: then everyone's code looks the same, so you don't have
Speaker 5: that kind of that meta attack, that side channel attack
Speaker 5: to spot the dodgy bits of a new code base.
Speaker 5: Am I am I am I am? I off on
Speaker 5: one there?
Speaker 3: Or is this a real thing? Now? You have to
Speaker 3: read the code during code reviews of what you're saying.
Speaker 4: So your linter is eliminating some of your priors for
Speaker 4: where your issues and the code might be.
Speaker 5: I think I think the LINTA is solving the easy bugs,
Speaker 5: like you've misspelled faarable name and yeah, you know you've
Speaker 5: got kind of riva cops picking stuff up, like this
Speaker 5: variable ward is never ever used and that's it. But
Speaker 5: by removing those low hanging bugs, what you have instead
Speaker 5: is a kind of faceless wall of perfectly statically analyzed code,
Speaker 5: and the kind of it just seems like bugs are
Speaker 5: getting harder.
Speaker 2: That's it.
Speaker 5: Bugs are getting harder, and lintus of the blame.
Speaker 3: That's exactly what we wanted it to do.
Speaker 6: That we wanted it to take away all the easy
Speaker 6: bugs that we can work on the hard one. Now
Speaker 6: you're complaining that they're all hard. There's no easy ones
Speaker 6: for you to point out. Some people just can't be satisfied. Okay,
Speaker 6: So getting back on topic. I actually wanted to revisit
Speaker 6: a thing, and I'm not I swear I'm not trying
Speaker 6: to set you up for failure.
Speaker 3: I just felt like we should probably address this. But
Speaker 3: you talked. You talked about your three strategies earlier.
Speaker 6: And how the sort of default one for us is
Speaker 6: this standard strategy, try out the place that I think
Speaker 6: the bug think, go to the next most likely place,
Speaker 6: and so on, right until I eventually find it.
Speaker 3: At some point you sort of have.
Speaker 6: To like bail out of that and be like, I'm
Speaker 6: not getting anywhere, I should try a different strategy. Do
Speaker 6: you have a sort of rule of thumb, even if
Speaker 6: it's not perfect for like when you start to bail out,
Speaker 6: I don't think that we actually called that out.
Speaker 4: Yeah, totally. When I am trying the same thing multiple
Speaker 4: times even though I already saw it didn't work, is
Speaker 4: usually when I like, if I haven't done it by then,
Speaker 4: that's the time.
Speaker 3: She wait until that point of anger for.
Speaker 4: Me, exactly when you've got like the orange face emoji
Speaker 4: is your actual face?
Speaker 3: That's fair?
Speaker 4: When do you usually bail out? How do you know
Speaker 4: when to bail out?
Speaker 3: I don't, but I'm I'm big into timeboxing.
Speaker 6: So I'm usually like, you know, all right, well I'll
Speaker 6: let myself If it's something that I start out in
Speaker 6: the first place saying I literally have no sense of
Speaker 6: where this thing is, right, then I'm just like, well,
Speaker 6: I'll give myself like thirty minutes maybe to like Sometimes
Speaker 6: I'll be like, I'll give myself like five or ten
Speaker 6: minutes right to like play guests and check, and then
Speaker 6: I like jump into like something else. But if it's
Speaker 6: something that like I feel like usually that process happens
Speaker 6: for me when I think I know where something is
Speaker 6: and then I start down the rabbit hole like with
Speaker 6: high confidence that I know exactly where this problem is,
Speaker 6: and then I just keep discovering that I don't know
Speaker 6: where this problem is.
Speaker 3: In that case, it usually.
Speaker 6: Happens that, you know, I either need to like get
Speaker 6: up for a bio break or like to go eat
Speaker 6: or something, and then I'm like, huh, I've been doing
Speaker 6: this for a long time.
Speaker 3: I should probably like stop. That's yep.
Speaker 4: Yeah, I run into similar And another thing that tends
Speaker 4: to happen to me is that I will be just
Speaker 4: banging my head against a problem with no luck for
Speaker 4: some extended period of time. And then convince myself somehow
Speaker 4: to put it down and walk away. And in the
Speaker 4: time when I've walked away, it's like I guess on
Speaker 4: a background process somewhere, and then it occurs to me, Oh,
Speaker 4: I haven't tried whatever this other thing. Maybe I should
Speaker 4: do that instead. And it happens so frequently that now
Speaker 4: I get into these mental battles with myself where I
Speaker 4: can't figure something out and I want to keep working
Speaker 4: on it because like, the more it doesn't work, the
Speaker 4: stronger my resolve grows to get it to work. And
Speaker 4: then I have to convince myself to walk away because
Speaker 4: for some reason, the more things don't work, the more
Speaker 4: determined I become that the next thing is going to work,
Speaker 4: which doesn't match up with the data at all. But
Speaker 4: I've gotten better about it. But it used to be
Speaker 4: a real problem.
Speaker 5: What about caffeine and alcohol?
Speaker 4: Oh man, So I do like my coffee in the mornings.
Speaker 4: I don't know if it makes me a better programmer.
Speaker 4: I do. I have noticed that if I if I
Speaker 4: try to like mess with the system after about five
Speaker 4: thirty PM, I'm probably just gonna end up breaking it
Speaker 4: in some kind of way where I have to come
Speaker 4: back in the morning and start from like behind where
Speaker 4: I would have started if I just stopped at five thirty,
Speaker 4: because I have to fix whatever I broke after five thirty.
Speaker 4: Like the best thing that's going to happen if I
Speaker 4: commit after five thirty is I'm going to have the
Speaker 4: system back at where it was when I started working,
Speaker 4: which is an.
Speaker 5: Issue I find. I sometimes I need both caffeine and alcohol.
Speaker 1: MM.
Speaker 5: The caffeine to motivate you to find a bug, because
Speaker 5: it's always, like, you know, the big ones, always the
Speaker 5: ones you don't want to look at right. So you
Speaker 5: get the caffeine to breave you up, and then eventually
Speaker 5: you reach the point of failure where you can't find
Speaker 5: the bug, and then the alcohol lowers your inhibitions and
Speaker 5: you start just trying crazier stuff.
Speaker 4: I like that idea as an inhibition inhibitor.
Speaker 2: I mean interesting.
Speaker 4: I wonder that's how it gets depicted in pop culture
Speaker 4: a lot too.
Speaker 5: Right, I was reading about these brain studies where people
Speaker 5: can't see stuff and they can spot spelling errors easier
Speaker 5: when they're tired or they kind of impinge their brain
Speaker 5: and suddenly they can kind of spot like the word
Speaker 5: the appearing twice in the sentence more easier. You had
Speaker 5: that kind of stuff.
Speaker 4: I haven't heard about it, but I believe you this
Speaker 4: is a okay.
Speaker 5: I'm sure this isn't something I've made up, But they
Speaker 5: kind of do something people's brains, either they make them
Speaker 5: very tired or they give them something, and then spotting
Speaker 5: spotting single characters spelling mistakes is easier because their brain
Speaker 5: is no longer functioning on that higher level a kind
Speaker 5: of reading. It's no longer kind of speed ring. It's
Speaker 5: kind of doing one step at a time, and then
Speaker 5: certain activities become easier. So this is an idea. I
Speaker 5: really take the heart in my foll where I am
Speaker 5: banging the head against a bull Doug hunting binges.
Speaker 4: I wonder if that speaks as well. In part of
Speaker 4: why pair programming works is that you can have one
Speaker 4: person focused on the overall strategy and code flow, and
Speaker 4: then the other person's focused on like, is this word
Speaker 4: in there twice? Does this match the API as it
Speaker 4: currently is? Are we using this variable? You could sort
Speaker 4: of employ two different levels of thought at the same time.
Speaker 6: That way, I don't I don't have an answer one
Speaker 6: way or the other. I was just going to say
Speaker 6: the way that I always thought that code programming just
Speaker 6: worked is you had somebody writing and then somebody reading it,
Speaker 6: and the person that reading it was like, what the
Speaker 6: heck is am I reading? And I always felt like
Speaker 6: that that sort of was how I saw it working.
Speaker 6: But I'm sure there's many things at play.
Speaker 3: It just works. I just trust it. So I did
Speaker 3: have a question.
Speaker 6: I think this is probably my last one for the day,
Speaker 6: but so this is kind of you've kind of touched
Speaker 6: on this before. You said that you're sort of interested
Speaker 6: in creating a language around debugging pedagogy, as you said earlier,
Speaker 6: things like that, it seems like you're sort of interested
Speaker 6: in this space there, I think. I mean, I take
Speaker 6: your point, like I get it, Like you're right, Like
Speaker 6: I literally have no words to describe my process, Like
Speaker 6: today I have some new words and some new systems,
Speaker 6: and that's really cool. Are there things that are like
Speaker 6: missing from here? Like are there things that we need
Speaker 6: to do to make this work? I was thinking as
Speaker 6: you went along that this seems like a societal shift
Speaker 6: you mentioned earlier. Actually I might be answering my first
Speaker 6: question and opening a new one.
Speaker 3: So you said earlier.
Speaker 6: Hey, we actually like basically reward people that don't debug well,
Speaker 6: and we're like not rewarding people that are basically by
Speaker 6: just rewarding people that are in bill mode all the time.
Speaker 6: So are there like problems across the board that we
Speaker 6: should be addressed saying how do we get to a
Speaker 6: better place?
Speaker 3: Is this is a good question?
Speaker 4: It is a good question. I think that there are
Speaker 4: a couple of different pieces to it, and one of
Speaker 4: them might be about the incentive structure that we use
Speaker 4: for measuring our I don't know, I value is the word.
Speaker 4: Are measuring our work as programmers or maybe as anyone
Speaker 4: and finding ways to model that so that it doesn't
Speaker 4: necessarily feel like a waste of time. And there's a
Speaker 4: psychological component to that, and there's an actual organizational incentive
Speaker 4: component to that. And then the other part would be
Speaker 4: learning more about bugs. So I'll address both of those,
Speaker 4: the first one being the organizational incentive part. How do
Speaker 4: we go about, you know, providing accolades and career oriented
Speaker 4: rewards to someone who is able to figure out and
Speaker 4: resolve this like thorny issue that nobody else has managed
Speaker 4: to figure or that has existed for a long time.
Speaker 4: How do we promote that to the level of like
Speaker 4: getting this feature out on time, because in essence they
Speaker 4: both they they do the same thing. The for the
Speaker 4: goals of the software, we want working software, which means
Speaker 4: the feature has to be there. But it also means
Speaker 4: that the feature has to be working, and we want
Speaker 4: to make sure that we are recognizing and rewarding both
Speaker 4: of those things. And maybe that's at the organizational incentive level.
Speaker 4: It's something for engineering managers and directors of engineering to
Speaker 4: think about on the psychological level. So I'm a big
Speaker 4: fan of and this is my mom. Growing up. My
Speaker 4: mom really loved mystery books and she kind of passed
Speaker 4: that on to me. She even wrote some mystery novels.
Speaker 4: She's very, very into the mystery. And I had various
Speaker 4: plans for what I wanted to be when I grew up,
Speaker 4: A detective, a spy, various types of things like that.
Speaker 4: Those I really did. It's a whole story. I'm not
Speaker 4: a spy. I already know somebody was about to ask
Speaker 4: me that, So no, I'm not.
Speaker 3: Things like that.
Speaker 2: That's exactly what a spy would say.
Speaker 4: That, That's immediately what people say when I tell them
Speaker 4: I'm not a spy. I'll let you come to your
Speaker 4: own conclusions about whether I'm a spy or not. But
Speaker 4: yeah so. But but one of the things that has
Speaker 4: kind of helped me psychologically make peace with long and
Speaker 4: onerous debugging processes is to imagine that I'm a detective
Speaker 4: in those scenarios, and this is a case, and you
Speaker 4: know which which cases to Detectives get rewarded for solving
Speaker 4: the really hard to crack cases. So regardless of whether
Speaker 4: or not there's any actual organizational incentive for me to
Speaker 4: go after this bug, I get to depict I get
Speaker 4: to picture myself as like detective Chloe Decker or whoever,
Speaker 4: and think of this as solving a case, which is
Speaker 4: this is helpful for me as an analogy that makes
Speaker 4: me feel like, you know, I'm getting something valuable done,
Speaker 4: I'm getting something cool done. It's not this isn't this
Speaker 4: isn't like a yak shaving type of task where I,
Speaker 4: you know, it just has to get done and that's
Speaker 4: the only reason that we're doing it. There's something for
Speaker 4: me to learn here, there's something there's a skill for
Speaker 4: me to develop here. I'm going to be a better
Speaker 4: programmer at the end. Of this because I've resolved this bug.
Speaker 4: So that's the organizational incentive and psychological side of it,
Speaker 4: and then there's coming up with better ways to understand
Speaker 4: and categorize bugs. So, because bugs are something that we
Speaker 4: largely have approached by an individual guest and check method,
Speaker 4: there's not a lot of good systematic research on bugs,
Speaker 4: where they come from, how they happen, what they look
Speaker 4: like we do see. So there are papers about like,
Speaker 4: does static type checking reduced bugs? Does this reduce bugs?
Speaker 4: Does that reduce bugs? But the so so I'll go
Speaker 4: ahead and say the denuma of that is that a
Speaker 4: lot of that research indicates that the two things that
Speaker 4: quote unquote reduced bugs are code review and developers getting
Speaker 4: adequate sleep, which is an interesting result. But the thing
Speaker 4: is that as you look into these studies, I'll just
Speaker 4: say this, looking into computer science studies can sometimes be
Speaker 4: a depressing endeavor because as we look into them, we
Speaker 4: realize that, like, the sample size isn't anywhere big enough
Speaker 4: to indicate a statistically significant difference a lot of the
Speaker 4: times or our there are multiple comparisons going on here,
Speaker 4: the statistical rigord doesn't tend to be very good, and
Speaker 4: in particular, in the case of debugging studies or studies
Speaker 4: of bugs, we don't have a good handle on what
Speaker 4: constitutes a bug, and so what happens researchers come up
Speaker 4: with proxies. They try to come up with these proxies
Speaker 4: to indicate what a bug is in a code base.
Speaker 4: And it'll be things like this isn't a fake example,
Speaker 4: and I understand why they did it. I don't think
Speaker 4: this is a you know, I get that it's really
Speaker 4: hard to figure out a way to say what is
Speaker 4: a bug and so, and you need, once again, a
Speaker 4: lot of samples to be able to do any research.
Speaker 4: So how do you find a lot of samples in
Speaker 4: a case where you're not really sure what a sample is?
Speaker 4: You try to come up with something that represents a sample.
Speaker 4: And so they'll say, we looked at these five code bases,
Speaker 4: and we decided that any commit that changes two lines
Speaker 4: represents a commit where there was a bug. Like, what
Speaker 4: kind of proxy is that? I don't think that's a
Speaker 4: particularly accurate proxy. Necessarily, there might be bugs where you
Speaker 4: have to change a whole ton of lines of code,
Speaker 4: or there might be a situation where like, I don't know,
Speaker 4: we changed deployment hosting providers and that's one line and
Speaker 4: it wasn't a bug. We just like changed, you know,
Speaker 4: we don't we make it's an assumption, it's an embedded assumption.
Speaker 4: We're assuming that a two line change equals a bug. Okay,
Speaker 4: what's the app curacy of that assumption? What are the
Speaker 4: false positives on that? What are the false negatives on that?
Speaker 4: So we really just don't have solid research on bugs
Speaker 4: in that way because in order to do that, it's
Speaker 4: really really tough to go back and retroactively figure out
Speaker 4: where the bugs were. You have to, in my opinion,
Speaker 4: have folks or in my perspective, at the moment. To
Speaker 4: get a good read on bugs, you have to have
Speaker 4: developers logging at the time of resolving bugs. What is
Speaker 4: the bug, how much time did you spend on this bug,
Speaker 4: what did the problem end up being? What are all
Speaker 4: of the things that you tried in the process. I
Speaker 4: think that a really solid, really insightful, illuminative study on
Speaker 4: bugs would require that kind of data collection, and that's
Speaker 4: a really really tough thing to do, but I mean,
Speaker 4: I love to do that. At some point. I would
Speaker 4: like to get a cadre of developers together who are
Speaker 4: committed to logging our bugs and how we resolve them
Speaker 4: and figuring out what patterns we can find in that.
Speaker 4: What took a really long time, what didn't take a
Speaker 4: really long time, What prior experience really helped me out here?
Speaker 4: Where am I translating skills from one code base to
Speaker 4: another codebase and stuff like that? And the data collection
Speaker 4: process would be super intensive, but I think it's something
Speaker 4: that hasn't been done and something that I would love
Speaker 4: to do and or see done. But I think that's
Speaker 4: where additional terminology would come from. Yeah.
Speaker 3: Cool, Well, I've got.
Speaker 1: To push this toward picks because I've got a hard
Speaker 1: stop in about fifteen minutes.
Speaker 2: This has been really enlightening.
Speaker 1: And yeah, if people want to participate in the conversation
Speaker 1: going forward, how do they get a hold of you?
Speaker 4: Oh? Man, So my name is Chelsea Troy. My site
Speaker 4: is Chelseatroy dot com. My email is Chelsea at chelseatroy
Speaker 4: dot com. My Twitter is Hey Chelsea Troy. I keep
Speaker 4: it consistent on the name as much as I can.
Speaker 4: But yeah, I mean I'd love to chat with people.
Speaker 4: Those are probably the places where you would find the most.
Speaker 4: I do have some blog posts about debugging already on
Speaker 4: the site. I'm happy to provide a link to the
Speaker 4: category or what have you for the show notes if
Speaker 4: that's helpful. But yeah, I'd love to talk to people
Speaker 4: about this kind of thing. I'm on a bunch of
Speaker 4: slacks too. It's possible if I'm on a slack that
Speaker 4: you're in. My handle is Chelsea Troy because that's what
Speaker 4: it is on all slacks.
Speaker 2: So yeah, awesome.
Speaker 1: Yeah, if we can get links to those in the
Speaker 1: chat that we'll put them in the show notes. All right, well,
Speaker 1: let's go ahead and do some pics. Luke, do you
Speaker 1: want to start us off with picks?
Speaker 5: I got to pick, I gotta pick. I've been working
Speaker 5: on a giant CCTV system that backs up about one
Speaker 5: hundred and forty gigabytes of video data day, which is
Speaker 5: quite a lot. And it's all based up a Mongo database,
Speaker 5: and the Morgo database likes to corrupt itself in the
Speaker 5: regular basis. We found that that bug. But we want
Speaker 5: to move some data off the server onto a kind
Speaker 5: of off site backup. We had the idea of sticking
Speaker 5: it in an NS three or a or a Google
Speaker 5: Cloud object story, and my colleague used our Clone, which
Speaker 5: I had not really heard of, but it was so
Speaker 5: both fantastically easy to get a database blob.
Speaker 3: Don't kind of.
Speaker 5: This was only one hundred meg but any any science works.
Speaker 5: It's quite a bust to get data into a Google
Speaker 5: Cloud drive or sports all kinds of different things. It
Speaker 5: was so easy to use and set up. My pick
Speaker 5: for this week is our clonearclone dot org. If you
Speaker 5: want to get data into the cloud from development an
Speaker 5: environment server, that is really really good. It's fantastically easy.
Speaker 2: Awesome, John, Do you have some picks for us?
Speaker 3: I have too this week.
Speaker 6: So I think this is probably more well known in
Speaker 6: the gamer community or whatever, but because I think that
Speaker 6: most of us in the developer community are using laptops,
Speaker 6: but I have I have to have my laptop and
Speaker 6: then also have dsktop machines, so I use a mouse,
Speaker 6: and I got one of these gigantic mouse pads that
Speaker 6: like goes under your mouth and like under your keyboard
Speaker 6: just like takes up every thing or whatever. And it's
Speaker 6: like I don't even know how to describe, like how
Speaker 6: much better it is than having a little like you know,
Speaker 6: a few inches by a few inches wide square for
Speaker 6: a mouse. It's just completely different experience, Like I don't
Speaker 6: run my mouse off the edge of my mousepad constantly
Speaker 6: kind of thing.
Speaker 3: It's great.
Speaker 6: I highly recommend that you can get them for fairly
Speaker 6: inexpensive too. I mean, they have plenty of expensive ones,
Speaker 6: but you can get inexpensive ones as well. I got
Speaker 6: a Razor one, and then I have like this cours
Speaker 6: Air one that I got for like five bucks actually
Speaker 6: because it was like on sale, Like you can get
Speaker 6: them for fairly inexpensive. So but yeah, I totally totally
Speaker 6: recommend getting like a gigantic freaking mouse pad.
Speaker 3: They're awesome.
Speaker 5: I second that I've got a massive one, and it's
Speaker 5: also wonderfully absorbent of anything you spill.
Speaker 3: All right, So there's that.
Speaker 6: And then the other thing that I was thinking about
Speaker 6: this week, I was just reminded because I got drag bank.
Speaker 3: So I've been a member of this Discord server for
Speaker 3: a really long time.
Speaker 6: It's apparently become popular, but it's like, so I'm really
Speaker 6: into mentoring and stuff, and and some friend like was like, hey,
Speaker 6: you should come join the server. Like, uh, it's just
Speaker 6: people like learning how to code, like answer their questions
Speaker 6: occasionally blah, blah blah, that'd be really cool. So I've
Speaker 6: been in the server for like, I don't know a
Speaker 6: few years at this point. But it's called the Coding Den.
Speaker 6: It appears to me on the surface to be like
Speaker 6: filled with mostly probably like college kids and stuff.
Speaker 3: But if you like ore into mentoring, you know, they
Speaker 3: could probably use some more mature people to do some
Speaker 3: of that.
Speaker 6: There are some of those people there, so if you're
Speaker 6: like into that, I'm just throwing this out there.
Speaker 3: It's the thing. So that's out there. It's apparently I
Speaker 3: found it the other day.
Speaker 6: It's like apparently one of like the most populous Discord
Speaker 6: servers on Discord too, so for whatever reason. But yeah,
Speaker 6: there's a whole bunch of people on there, asking questions
Speaker 6: and helping other people.
Speaker 3: So I got nice.
Speaker 1: I don't know if I'm more mature, I'm more seasoned. Anyway,
Speaker 1: There we go, right, I like spicy, Yeah, there we go.
Speaker 1: I've got a few picks and I'm going to push
Speaker 1: out there. Lately, I have been listening to the Wheel
Speaker 1: of Time books on Audible and they're terrific. And I
Speaker 1: don't remember who the narrator is, but he's also pretty terrific.
Speaker 1: There are two of them, There's a man and a woman,
Speaker 1: and they kind of depending on which point of view
Speaker 1: you're getting the story from, Right, if you're getting it
Speaker 1: from a male character, then it's the male narrator, and
Speaker 1: if it's a female character, from the female narrator. But
Speaker 1: they're they're really well done. I really really enjoy those,
Speaker 1: so I'm going to pick those on Audible. And then yeah,
Speaker 1: I've been onboarding with a company. I'm not going to
Speaker 1: announce where I'm working, but things kind of slowed down
Speaker 1: with the podcast network to the point where I in
Speaker 1: order to pay the bills, you know, I had to
Speaker 1: go find some other work. So anyway, the onboarding process
Speaker 1: has been excruciating. But they did send like a box
Speaker 1: full of hardware right with the laptop and stuff, and
Speaker 1: they had like this really inexpensive Logitech wireless.
Speaker 2: Mouse, and I really like it, so I'm going to
Speaker 2: pick that.
Speaker 1: I'll find it on Amazon and put a link in
Speaker 1: the show notes, and yeah, those are my picks. And
Speaker 1: then also, of course most Valuable Dot Dev We're going
Speaker 1: to be doing monthly Q and A calls, probably get
Speaker 1: an expert or one of my co hosts from one
Speaker 1: of the shows on to talk about stuff and teach
Speaker 1: us stuff. And then I'm putting together a summit in
Speaker 1: December and I'm going to have a whole bunch of
Speaker 1: experts essentially get on.
Speaker 2: And the idea is is, you know, if you were
Speaker 2: if you woke.
Speaker 1: Up tomorrow where nobody knew who you were, you were
Speaker 1: kind of a mid level developer who was competent at
Speaker 1: their job and didn't really know what to learn next,
Speaker 1: you know, what would you do to become the most
Speaker 1: valuable the most valuable developer on your team. So it's
Speaker 1: just going to be an it's going to a series
Speaker 1: of interviews. But that's that's what I'm looking at doing
Speaker 1: for that that summit. And if you want to just
Speaker 1: get the videos as they come out, that'll be free.
Speaker 1: They'll be free for a day or so. And then
Speaker 1: if you want, you know, longer access and access to
Speaker 1: a Slack channel and scheduled q and a's and stuff
Speaker 1: like that with them in Slack, then you know, you
Speaker 1: can buy a ticket.
Speaker 2: So that's that's how I'm looking at doing that.
Speaker 1: That way, the folks who are in areas where they
Speaker 1: can't afford it, or if you're between jobs. I mean,
Speaker 1: you can just get the free ticket and show up
Speaker 1: and participate. So so yeah, so that's what I'm looking
Speaker 1: at doing there, Chelsea. Do you have some things you
Speaker 1: want to shout out about?
Speaker 4: Yeah? Absolutely, I got some picks. So the first one
Speaker 4: is a book that I've been reading recently. It's called
Speaker 4: The New Educations by Kathy and Davidson, and it is
Speaker 4: about the American chiefly higher education system, and where it
Speaker 4: came from, why it is the way it is, and
Speaker 4: what we might potentially change about it. Now, I'll issue
Speaker 4: a reservation on this book, particularly with regard to tech.
Speaker 4: Some of the tech claims that it makes are not
Speaker 4: accurate exactly. But with regard to the teaching portion specifically,
Speaker 4: there are a lot of case studies and examples in
Speaker 4: this book of teachers who've done really interesting things in
Speaker 4: their classroom to help engage the students and help the
Speaker 4: students actually participate in meaningful projects that make positive changes
Speaker 4: in the world in areas where the students care about
Speaker 4: as they're in the class. It's really cool. I took
Speaker 4: a whole bunch of notes from it. I'm going to
Speaker 4: be doing some stuff with the exercises from that book.
Speaker 4: I think as experiments in my mobile software development class
Speaker 4: this fall, So I'm pretty excited about that. It's called
Speaker 4: the New education. And I guess the other thing, maybe
Speaker 4: this is to to cliche for the Ruby Rokes podcast,
Speaker 4: But at Ruby Kanf twenty twenty this year, remote edition,
Speaker 4: I am going to be co leading a workshop about
Speaker 4: software maintenance and risk mitigation mechanisms that are pretty excited about.
Speaker 4: The case study that we're doing is a three device
Speaker 4: system where some software all collaborates together to help a
Speaker 4: parent emergency room keep track of all of its parent patients.
Speaker 4: So parrots lives are going to be on the line,
Speaker 4: and mitigating risks in the software is going to be
Speaker 4: in your hands as participants. I'm really excited about it,
Speaker 4: and I hope that you will join me there in November.
Speaker 2: Awesome, looking forward to it, and thanks for coming, Chelsea.
Speaker 3: This was really fun.
Speaker 4: Yeah, absolutely, I had a great time. Thanks for having me.
Speaker 1: Yeah, thanks for coming. All right, folks, we'll wrap this
Speaker 1: one up until next time.
Speaker 2: Max Out