At this early point in the Fall semester, I am finding Javascript to be surprisingly easy to pick up. Previous to this course, I have not gotten more than a cursory glance at coding in Javascript, but having already had experience with a few other programming languages, namely Java and C/C++, the general structure of the language was very familiar. Additionally, as far as things go, it seems to be a very forgiving language, in that variables do not have to be declared as specific types and getting code to run is not as technical as with C. Getting code to run nicely has been the smoothest process I’ve had yet with a new language. Although, I do find myself having to catch myself from coding in Java or other similar formats, as it is what I am used to and I am still getting acclimated to Javascript.
Thus far into learning how Javascript works and how to write code in it, I have not really learned anything new. Mostly its been dusting some cobwebs off of my prior experience with similar concepts and formats from other languages I have learned previously and figuring out how they apply to Javascript. I think as far as judging if it is a good or bad language for software engineering, in my limited experience with it so far, that it is a very good language to use, at least in a learning environment. It is relatively easy to use syntax wise, as in I can just type some code out and have a simple functioning program, thus I can assume creating more complex programs will be similarly easy to create, and it looks to be able to handle complex code just as easily as Java or C/C++ can.
Today my class completed its first official WOD, or Workout Of the Day, an exercise where we are given a task/problem to code and a time limit to complete it in; a technique of athletic software engineering practices. The task given this time was to code an algorithm, “BoogieWoogie”, based exactly on the “FizzBuzz” problem often presented in programming job interviews. To prepare for today’s time trial we were given a few practice WODs, which proved very useful as they illustrated the concepts we might be tested on and gave me a feel for how expeditious I would need to be in writing my code. Coding under a time limit and going in relatively blind is something that I and others will likely encounter in job interviews or other situations in our lives later down the line and this style of learning promotes acclimatization to the stresses and challenges that come with these situations. I personally do not enjoy strict time limits, even in gaming I try to avoid such segments of gameplay whenever possible, but I do find having them can bring out a great deal of focus and will often garner good results in the end. Therefore, while I understand the benefits of athletic software engineering and do think it will work for me, I do not think I will ever really enjoy it past the feeling of accomplishment that comes with completing a challenge whilst within its parameters.