Week One ➙ Iron Yard Reflective Journal

“Diving into vanilla JavaScript”

Diving into week one of the Iron Yard has definitely been an intense but exciting experience, and is unlike any other daunting challenge I’ve ever attempted. Learning JavaScript is a process replete with rabbit-holes and fascinating but maddeningly complex puzzles… Nevertheless, I already feel like this program is giving me some great insights into best practices vis-à-vis efficient front-end-engineering workflows and fundamental design philosophies.

As burgeoning developers, we’re finding manual or repetitive processes and automating them, entrepreneurially looking for problems that websites can conveniently solve or new services they can provide, building more efficient workflows for users, and generally trying to make people’s lives easier with more interactive and functional websites. Expert developers like our instructor even automate many of their own processes to make their workflows much faster and easier…

Thus far, I’ve learned that enumerating and clearly describing web-application specifications is crucial to efficiency in approaching the design process. User-Stories are a very fundamental and concise way to to initially achieve this without too much scope-creep. The concept of a user-story is simple: “In order to get some benefit, a someone can do something.” Alternatively, and perhaps more amusingly: “a smurf can smurf so that smurfs can smurf.” Essentially, one should design from the outside-in by distilling “big-picture” crucial functions from a user perspective then build from the inside-out in an iterative manner, adding features gradually once each deliniated aspect of basic design with separation of responsibilities is achieved. One aspect of this approach reminds me of the “keep it simple stupid” (“KISS”) principle — in other words, “explain like I’m five” and then figure out the most straightforward approach for how to engineer that function.

In implimenting this process, one should strive for encapsulation: making sure that everything needed to do one job (following the single-responsibility principle) is right there and readily available for each iterative piece of one’s code as it executes flow control… This is the technique we employed in attempting to build TodoCLI with basic JavaScript. Moreover, it’s clear right from our first assignments that JavaScript is an event-driven language (such that anything the user does in a browser to interact with a website, or even simply jammin’ in the console, can trigger functionality in JavaScript).

Another great principle to keep in mind is an adage of “Extreme Programming” (“XP”) called “You ain’t gonna need it” (“YAGNI”), which states that a programmer should not add functionality until deemed necessary! This way, one can start with the basics, get an application up and running, and then add more advanced functionality or bells-and-whistles later.

While writing software in an iterative manner, I’ve learned that one shouldn’t get attached to anything, since one will make lots of drafts and throw away lots of junk in the process of creating something functional… I’m confident that being able to educate others on one’s team regarding these sorts of methods and learn from them using these methods will be an important skill to demonstrate in my portfolio.

Some of the many great methods we’ve learned so far include, but are certainly not limited to:

• sanity-checks
• tracer-bullets
• embracing test-driven development, especially initially
• focusing on expectations, returns, and side-effects
• red, green, refactor
• arrays are extremely powerful and multi-functional
• functions can be tricky rabbit-holes with Inception-like nesting potential and multifarious possible uses or applications in many cases
• syntax and muscle-memory typing is important in building basic core skills as a developer
• JavaScript koan meditations… are helpful in understanding concepts beyond merely getting code to work
• API basics and building that into MVC models are crucially important to focus on in terms of design philosophy