When all you have is a hammer, everything looks like a nail…

I recently posted about an overly elaborate solution that I wrote to a CodeWars algorithm. That post has been lurking in the back of my head since I wrote it…

I’ve come to realize that I can’t be too hard on myself for coming up with the solution that I did.  After all, the only tool I had available to me was a hammer, so I treated every problem like a nail.

Man Hammering Nail
An image of me writing code

My point is that up until then, any time I had to traverse an array, I had used a for loop rather than any of the methods native to the array prototype.  Setting the conditions of the loop to something like (var i = 0; i < arr.length; i++) allows you to easily access and manipulate any element of the array using arr[i].  So that’s what I did…

While there’s (usually) nothing inherently wrong with that (in fact, it’s how I solved many of the algorithm challenges at Free Code Camp), loops aren’t always the most elegant solution to a problem, especially when you start to consider asynchronous options in your code.  Besides, the point of this journey is to become the strongest developer I can, so let’s explore other options.

While going through the front end program at Free Code Camp, I was exposed to many of the methods in the array prototype, including forEach(), reduce(), map() and filter().  The problem was that those methods required callback functions, of which my understanding was tenuous, so I found it much easier at the time to use loops.

Working with Node.js these past few months has given me much more exposure using callback functions, so I’d like to revisit these methods and solidify my understanding of them.  That way, when I encounter problems in the future, I’ll have more than one tool at my disposal.

Over the next couple weeks, I will write a post that will cover each of the four array methods mentioned above in detail.  Hopefully, these posts will serve as good resources for others in my position and, at the same time, give me extra practice using each.

I’ll be sure to come back and provide links to the follow up posts once they’re written.

That’s it for now, thanks for reading.


JavaScript Fatigue, or in my case JavaScript Paralysis…

Since starting FCC in March I’ve made pretty steady progress through the curriculum.  Of course I’d like to be moving faster, but considering all the other commitments in my life, I’m happy with my pace thus far…

That is until the past few weeks…

I was moving right along through the back end program.  Learning Node and Express was going well and I got through the API projects relatively quickly…

Then I moved on to the voting app, the first of the Dynamic Web Application Projects.

I’d previously experienced so-called JavaScript Fatigue, or the overwhelming sense you get at the thought of all the frameworks, libraries and tools associated with JS.

The past few weeks, though, it’s hit me something fierce…

photo by Windell Oskay
photo by Windell Oskay

While thinking about how to approach the voting app I considered using a framework, maybe React or Angular 2.  So I dug a little deeper…

As someone still relatively new to the JS world, comparing React and A2 isn’t exactly easy.  How do I compare JSX vs TypeScript if I haven’t seen either?

Babel and Webpack.  Huh?

Redux?  Flux?  WTF??

Bring on the JavaScript Paralysis…

I’ve spent the past couple weeks paralyzed with indecision and frustration…

Photo by Kenny Loule
Photo by Kenny Loule

When I was thinking about writing this post, I made a quick list of all the JS libraries and frameworks that I could think of.  In about 2 or 3 minutes I came up with 39 of them!!

Off the top of my head!!


I have the scrap of paper to prove it!  No wonder JS fatigue is a real thing.

Moving on….

Look, I’m not going to go on and on here…  There’s been a ton written about JavaScript fatigue lately, most of it far more eloquent than this…

I just wanted to put this out there in case anyone else in the Free Code Camp program was going through the same thing.  Plus, I’m hoping this will serve as a bitch session to get it off my chest so I can move forward.

I’ve decided to say F-it and move on without a framework for the time being.

I plan on building 1 or 2 of the full stack apps without a framework, then decide between moving forward with either React or Angular 2.

At that point, I’m hoping FCC has updated their data viz section and the decision will be a little easier.

That’s it for now…  Get out there and code something cool, I’m certainly going to try.