Today was kinda difficult to motivate myself to do…when the next video is called “Debugging Your Code” and its 11 minutes long and it’s freaking New Year’s Eve and I have no groceries cause I just got back from my trip so I’m starving to death and you know what fuck it I’m done.

Experiment’s over. No more coding, no more chain.

Naw jk I finished it and it has some good stuff. Gotta be honest, I didn’t finish it in one go like normally though. First it talked about the importance of understanding the compiler; the compiler gives you a lot of information on what went wrong, where, and why, and it can be invaluable to deciphering what you did wrong.

Next we went into rubber duck programming. Way ahead of you, devs; not only is this blog serving as my outlet, I’ve got Brenna the Rattata sitting beside me on my desk if I need real-time assistance.

Brenna

We moved onto a dire warning never to assume, because assumptions can cause fundamental problems when you build your code around them and they turn out to be wrong. I’ve spent enough time making games in Multimedia Fusion to 100% understand that concept; its awful when the problem turns out to be “you copy-pasted stuff into the wrong line” and everything you did was technically correct in your head, you just didn’t lay it out on paper the right way.

Then we moved into the Minimum Viable Test case, a good guideline for removing all extraneous code and narrowing it down to just the code that isn’t working. I’ve done this before, though I prefer the “create a new project that only uses the bit that isn’t working,” an example of me doing that is here. I guess that’s a bit closer to the “Scientific Method” idea they describe after that.