Transcript from the "Understanding Your Code" Lesson
>> Kyle Simpson: So let's take a look at the spec for the ++ operator and in this case, the postfix operator, since that's the one in question. You'll notice that it is written out, and most of the spec is this way. It is written out in the sorta numbered algorithmic format.
[00:00:16] The good news is you're developers, and developers read and write algorithms all day long. So while there are certainly some challenging parts to jumping into the spec, and I don't wanna wash over that the spec is just immediate, it's easy reading. That definitely takes work. But while there are certainly things that can be challenging about reading the specification, even just reading these couple of snippets, these five items in this bool list, there's a very straightforward algorithm for determining what to do.
[00:00:48] Now the reasons behind the algorithm are an entirely different topic. And whether it's consistent with other algorithms is a totally separate topic. But if we wanna understand what the ++ operator is doing, predict it and avoid problems. The only way to do that is to understand what it's gonna do.
[00:01:22] I think one of the things that creates the biggest roadblock to our effectiveness as developers is that we code without really knowing what we're doing and then we hope that we don't run into a bug as a result. It's interesting to me, I've ask this question and I've only ever gotten one answer that made any sense.
[00:02:06] Like I constructed the X equals X plus one, which is reasonable by the way. I'm not suggesting if that's your mental model that you're weird for thinking that, it's reasonable, but we artificially construct these mental models, and it seems to work, and so we say, I hope the test suite passes.
[00:02:23] Can you imagine an architect of this building saying, I hope the walls stay up, and I hope the roof stays on? Let's put people in it and see how it works. Let's run the tests and see how it works. I don't know of any other way of developing a confidence over your code.
[00:02:39] But it's what I'm striving towards, to be able to understand what the code is doing. And right here in this particular spec, it tells us exactly what happens. It grabs the old value and does the two number operation on it. It turns it from whatever it is into a number.
[00:02:53] And we're gonna talk about that two number that's called an abstract operation. We're gonna get into that in this course. But I want you to be able to be comfortable enough that, if you didn't understand something, you could check MDN. But guess what? MDN is not always [LAUGH] right.
[00:03:28] It's an operator, but it's like a function that takes the original X. And right there on line 4, it coerces it to a number. And it returns that original number after having updated it with the increment of one. So this is an illustration of having a more clear mental model, and the only way that I got that was reading this back.
[00:03:50] I saw something that I expected to have happen. It didn't happen, and I noticed that's my lack of understanding, I have the wrong mental model. And there's one way to solve that, read the spec. Whenever there is a divergence between what your brain thinks and what is actually happening in the computer, that's where bugs enter the code.
[00:04:11] And that's really what I'm getting at, the thing that causes you to be frustrated as a developer is that bugs happen in unexpected ways and I think one of the most common ways that bugs enter is we have the incorrect thinking, the incorrect mental model. We're thinking something but then it's a divergent to what we're thinking and what the computer's doing and that's when the bug enters the code.
[00:04:32] I mean yes, there are bugs that happen because you just accidentally type two instead of three. That happens. I'm not suggesting that all bugs are this way, but I think that the predominant set of bugs that occur is because we're thinking one thing and something else is actually happening.
[00:04:49] You're gonna hear a lot throughout this course, but this is one of those sayings that I will repeat on a regular basis, and people like to refer to these as getify's laws. So I went ahead and just started numbering them. So this is getify's law number 17, when there's a divergence between your brain and the computer that's where the bug enters the code.