Reflecting on JavaScript and Athletic Software Engineering

19 Jan 2017

Initial Thoughts on JavaScript

Completing the JavaScript 1 module from my Software Engineering course (ICS 314) gave me the impression that JavaScript is a solid language for software engineering. Not only does the language seem to offer a lot of versatility without any inconvenient complexities, but takes aspects of popular languages such as C++ and Java. In addition to being a solid language, the method in which I’m being taught the language in my Software Engineering class further enhances my ability to understand JavaScript in a quick and efficient manner.

One interesting thing about JavaScript I learned from the module are the distinct differences between the 3 datatypes: var, let, and const. Withh prior experience using JavaScript in my Databases class, it didn’t even occur to me that I should consider using other datatypes aside from var. Since the course was more focused on learning SQL instead of JavaScript, I just wasn’t informed about the problems that may result from using var until I learned about it from my Software Engineering class.

If you are unfamiliar with JavaScript, var, let, and const are the main datatypes used for defining variables. Const is used to define variables that can’t be changed at runtime, and var and let have similar uses to each other, but scripting language standards like the ES6 encourage you to use let as much as possible instead of var because of the major differences between functional scoping and block scoping. With var’s functional scoping, instantiating any variable of type var sometimes yields unusual behavior in variable accessibility. In hindsight, block scoping with the let datatype performs more similarly to what we’d expect a variable to perform with any other programming language. Aside from the differences in datatypes which I found interesting, I really liked the idea of function encapsulation (a function inside function). Compared to other programming languages, I haven’t really come across any that allowed a function to be defined with a function inside of it.

Is JavaScript a Good Language for Software Engineering?

From a software engineering standpoint, I think versatility like this would only help in developing programs. I’m personally against the idea of restricting one’s creativity with the language they’re using. In my humble opinion, restricting one’s creativity in such manner is like telling an author to write a story only with exclamation marks for punctuation. The story might end up being creative, but the restrictions were still impractical and limited the writer’s options. In retrospect to software engineering, I have a similar belief. Even though restrictions could boast creative thinking, I believe having restrictions on something as fundamental as a language is the wrong means of trying to produce creative solutions. People should be allowed to freely express their creativity and develop software without any impractical nuances in their language of choice. So far, I’ve found JavaScript to be a language with a lot of options which provides a lot of possibilities. Due to this versatility, I think JavaScript is a good programming language.

Athletic Software Engineering

In my Software Engineering class taught by Philip Johnson, he teaches the material in the form of “athletic software engineering” as a means of improving the speed of finding high quality solutions to problems as well as achieving the following:

  1. Gain fluency with your tools and technologies.
  2. Gain the ability to focus and enter the “flow state” during software development.
  3. Become more productive and useful in “bursty” development environments like startup weekends. (Source of info)

In addition to an athletic software engineering approach, my class also uses the “flipped classroom” style of teaching. Being someone who struggles with concentration problems, I think this approach suits my learning needs better than a traditional, lecture-style, method of teaching. Whenever I took a course with in-class lectures, I found it extremely difficult to stay attentive, understand the material being taught, and not fall asleep. This form of passive learning has been highly ineffective and did not incentivize student learning. Without incentive, I had hard time creating the best possible work if there isn’t much reason to believe that my work even matters to the one professor or TA who must grade hundreds of papers just like mine.

Unlike lecture-style learning, athletic software engineering in combination with the flipped classroom is an active form of teaching. In class, I’m required to participate in activities such as the “Workout of the Day” (WOD), a timed coding exercise, and encouraged to mingle amongst my classmates. This style of teaching generates a friendly learning environment not only because every student is better kept engaged, but provide a hands-on experience to learn the material. Keeping the students engaged in activities makes it easier to stay focused, understand the material, and stay awake.

Although stressful, I think athletic software engineering and WOD’s will teach me to become a better software engineer. I’m glad the professor gives us practice WOD’s as a means of preparing for the actual WOD in class. Right now, my biggest challenge with the practice WOD’s isn’t the coding exercise itself, but the discipline and integrity required. With the solution video on the same page as the practice WOD, it’s very tempting to cheat myself and see the solution before my first attempt. Yes, this may save me some time, but in the end, I’m only hurting my own learning by doing this. If I keep my sense of integrity when doing the practice WOD’s, I think the exercises will work for me.