I've really enjoyed my Springboard experience so far, but one of the critiques I have towards the prep class (and something I brought up to the staff) is how long it takes to discuss using console.log to test code. To clarify: Colt, the instructor, uses it quite often, but it isn't until later that we are introduced to the concept. As a result, I wasn't aware of why he was using it until several lessons later, and even still, it took some extra studying to understand its importance.

However, it wasn't until earlier this week that its significance was really cemented for me, and it took playing a video game for me to figure it out.

Back on the 8th, Nintendo released the next entry in the much-beloved Metroid series, Metroid Dread. I've been playing these games as long as I can remember, so picking up this one was a no-brainer, even with the limited amount of time I can devote to games these days. (This was the case before starting the bootcamp; working full-time and not forsaking your family doesn't leave a lot of room for being a shudder "gamer.") I had heard Dread was fairly ruthless and unforgiving, and let me tell you: they (whoever they are) were not lying. At all.

While the E.M.M.I. robot experiences are stressful, I want to focus on the boss battles, as they are not necessarily difficult, but this is where the importance of testing really sunk in for me. As I was fighting the second major boss (no spoilers, I promise), I found myself overwhelmed, dying time and time again. Metroid games are definitely not your typical "aim and shoot" kind of games; it's important to plan and be methodical. However, this situation felt like it required me to unleash a non-stop assault on the boss... Only for me to realize, "Nope, I'm going about this the wrong way." Which is when I started dying on purpose.

Starting with this boss, and moving forward, I've never gone into a fight expecting to win the first time. I've begun watching the ways the enemies move and react to my movements. I'll try something, see how it works, and if it doesn't? I'll try something else. If it appears my plan worked, but maybe not how I expected? I'll try it a few more times, make sure it wasn't a fluke or if there is a way to improve my approach.

Simply put, I began "testing" these boss fights, and as a result, I felt more confident about what I was doing, and the successes felt more worthwhile. No, I didn't win on the first attempt, but that's also not the goal, nor is "winning with no damage incurred." Sure, that's a cool bragging right (I guess), but ultimately, the point is to move forward, correct?

In approaching the game like this, I realized I hadn't been taking testing my code seriously enough. This week I completed my first actual assessment, which was to create a meme generator, and although I finished it under the time the course estimated it'd take, I still found myself stumped time and time again. For example, I was able to generate a meme with the top and bottom text, but if I generated another meme, the top text for the new meme would overlay over the first top line of text, and both bottom lines of text would move to the bottom of the second image.

Needless to say, this was not ideal.

So what did I do? I started console.log'ing the bajeezus out of my code. I simplified everything down as much as possible to see where it was breaking down. If my function returned the message? Then it wasn't the function, it was my subsequent argument. If the argument returned the message, but it still wasn't displaying properly? Probably need to look at my CSS. The list goes on and on.

This wasn't the only time I used console.log for my assignment. There were several other instances where it came in handy. However, it was at this point where I felt like the wall in front of me was insurmountable. "How can you be so close and not get it?", my inner "Bruno" kept telling me. But thanks to my newfound discipline of testing my code, I refused to sit in defeat, and low and behold...

Well, looks like I still have some testing to do.