JavaScript and I
18 Jan 2018
I’ve had previous experience with Javascript. I took a Scripting course last semester where we used Javascript to edit various aspects of the DOM, and also retrieving data and manipulating it. I also actually just started using FreeCodeCamp during this past Winter Break - If you look at my FreeCodeCamp Map, it has all the previous sections right before basic Javascript. So in that sense, I didn’t really learn much fromt he last few assignments, but they were helpful in helping me refamiliarize myself with the JavaScript syntax.
I feel like I’m not far enough in my Software Engineering journey to comment on how good a language is, but I will say I am impressed with what is being done with the langugae. The recent development of taking JavaScript to the back-end, and using Javascript as more than just front-end stuff is incredibly useful, and reminds me of my brief learnings with Ruby and their web framework, Ruby on Rails. Being able to use NodeJS to bring Javascript out of the front end stuff looked very cool, but I would love to hear the thoughts from an old timer, someone with lots of experience with the back-end.
I personally don’t believe in a “Jack of all trades” kind of deal, where you can use Javascript everywhere. I believe each tool has a great purpose, and while it’s useful to have a tool that can do lots of different things, we should stick to using the tool for what it’s best at. Now does that mean Javascript might not be the best tool for the back-end, I’m not sure. I’ll leave that for the smart guys to figure out in California, and get to work learning how to program.
For the WODs, I like it. I was watching “The Social Network”, where Mark Zuckerberg decided who got to be an intern by making the candidates battle it out, taking shots every few minutes. It looked very cool to me, and WOD has that similar feeling. If this concept is used for learning, I don’t think it will be very effective at all. Some of the smartest people I know think slow, act slow, but produce better results than anyone else. This could be the same thing for coding. Take our first WOD for example, JabbyWabby. Immediately off the bat, I saw two ways to do this problem, brute force and an elegant algorithm. I picked brute force and got the thing done in < 4 minutes, but if I wasn’t timed, I never would have chose that option. It wasn’t the best way to solve the problem, and would never fly in a real life scenario.
I’m not sure about the other WOD’s we will do, but if it the same concept, where you can use the brute force way and hit your mark vs implementing an algorithm and hitting the time “DNF”, then yea, we won’t learn. But damn if it’s not entertaining. I think the best way to get the best of both worlds is to impose a runtime constraint. You must implement this solution in O(1), or O(log n), etc. That way not only can we work under pressure, but produce diamonds as well.