I’ve spent the last couple months trying to get more familiar with JavaScript and deepen my understanding of the language a little bit. If you missed the earlier blogs I made about what I’m learning, you can see them here and here. These might be some somewhat obscure topics and not your typical “Learning Objects” or “Arrow Functions!” type blogs that cover broader useful ideas, but like I’ve said before, my brain understands things better when I understand the small things in greater detail. Since so many of the algorithmic challenges I’ve been working on require some type of iteration, I wanted to talk about these two additions with ES6.
If you’re new around here, I’m posting some of the practice coding challenges I try. They might not be the hardest or most complex ones you’ve seen, but I like to post the ones that I think carry over some practical use in real coding environments. Lately, I’ve been trying to get a few challenges in on Codewars, so that’s where this next challenge comes from as well. This is a challenge in which I’m sure there are so many ways to approach and solve it, so let’s see if how I solved it compares to how you would try it.
I’m someone who really likes to know why and how something works the way it does to get a good understanding of using it. This goes for sports, it goes for nature, and I’ve learned it goes for coding as well. It was one of my biggest stumbling blocks early on with Flatiron- we learned when to use different bits of code, but it never really sunk in until I took the time to understand why that code goes there and how to use it going forward. So after graduation, as I’ve gone back through a lot of what I learned from the top level from June to November, I’m now trying to go a level deeper in my understanding (currently in JavaScript) so I’ll quickly be able to remember concepts as a whole and not just something I learned once. A word I feel like I’ve encountered 100 times in my reading is closures. Though I’ve seen it so many times, I don’t think I could give you a specific enough definition of it that meant anything. So, let’s see if this helps (both of us.)
If you read my blog a couple weeks ago or the one from last week, you’ll know that I’m currently working on building upon my Vanilla JavaScript foundation with lessons and coding challenges. Sometimes this looks like researching different JS methods I may be less familiar with, and sometimes it may be me working through some challenges on HackerRank, Codewars, etc. I’ve found that the difficulty of the challenges (for me, at least) doesn’t always match up with the reward system for each site, so I like to bounce around to different levels to see what I can do. I liked this challenge enough to post about it today, because a) I thought it used pretty practical skills to have brushed up on as a programmer, and b) I thought the story scenario was pretty fun/funny.
While I’m in the midst of searching for jobs, I’m also trying to work hard at learning more JavaScript topics I currently have a surface level understanding of. Maybe I have enough of an understanding to have used it in a project before (or maybe not), or maybe it’s something I’m learning so I can use it in a project sometime soon. Today, I wanted to study, and explain, Async/Await.