This week was quite interesting. For starters, the only thing I understood about JavaScript coming into this course was that it was difficult to understand (compared to HTML/CSS). But I didn’t exactly know what I didn’t know.

This week’s lessons were useful for showing us what JavaScript is used for, from adding and subtracting to serving as a foundational tool for bigger-picture project display. I’m definitely going to have to go through the lessons again (and again) to remember how the consoles work with each other (and sometimes exist inside each other, which was confusing at first). But overall, it was pretty clear.

Seeing how if/then questions are answered through programming was also interesting. I always knew that behind responsive design, some programming logic has to be in place for the page’s display to adjust to whatever the user is doing. Starting from smaller if/then statements and then building and adding conditions for more complicated, data-laden graphics is neat, and it gives me a whole new appreciation for the work my office’s developers do on a daily basis.

One question I have, though, is about the commenting language within the script. Since it’s expected for us to link HTML/CSS/JavaScript pages together, why are smaller functions (such as the invisible commenting function) not consistent across the board? Wouldn’t it be reasonable for some of the rudimentary labeling factors to be consistent?

Other than that, I am appreciative of the in-depth comments on my previous assignment. Things are looking much clearer now with regards to page organization. In fact, I was originally not as concerned about having clean (perfectly and consistently indented) text on my code page as long as it works. Now, I see that unorganized work (even if it displays exactly what you’re looking for on the front end) is a bad habit that will result in unnecessary frustration as the page gets more and more jumbled.

This week was interesting. It was good to have the chance to apply all of the HTML and CSS skills we learned from previous lessons. And I love how user friendly the lessons are after we complete them, allowing us to review past work. Formatting the page and figuring out what I need to add (tags, for instance) was not the most difficult part, though.

I think the most difficult part was figuring out all of the necessary steps for GitHub. I went through some tutorials online, and most of them pointed me in the direction of a few steps not discussed in class (Terminal), and it is a bit challenging when you know the major steps but a few minor steps in between are fuzzy. Regarding the readings, I think I was able to get everything up OK with refreshers.

Going back to the lessons, I think it was the “A Closer Look at CSS” lesson that provided a great example in the beginning about such a seemingly minor step (not linking the HTML and CSS pages) taking away the design of the entire page. The page on selectors was really helpful, as well. It answered questions I did not yet have, and it gave shortcuts (p, h1 designating the same thing instead of two different ones) that seem minor in the beginning, but offer large returns regarding time saved in large projects toward the end. And noting that we use !important as sparingly as possible is also… important. As it could be near impossible to figure out why, given the natural evolution of a webpage over time, specific elements are unnecessarily stagnant.

I think I just need to reread some of the lessons, especially the GitHub tutorial, to solidify and mature the seeds that have already been planted. I’ll do that some this week, in addition to the assignments for this week. Hopefully this is just an introductory learning curve that, just like FromSoftware games, I have to get over to git gud and be successful.

This week’s assignment was good. It rekindled my burning frustration with forgetting to close p tags, but the Codecademy setup was so intuitive that my questions were resolved almost immediately. I remember using W3 for learning to code in one undergrad course, and the user-friendly nature of this homework workflow (at least, so far) is far easier than editing in a notepad locally and refreshing the page.

Another point of reflection I’d note was the music. In fact, it was quite funny because I immediately thought of music (basic seven notes) before the actual guitar reference. Bringing things into perspective is a lot better for digesting. Just like learning a basic 2-chord song (HTML) for starting off is better than introducing a beginner to jazz standards (JavaScript). Whenever I try to encourage other people to play an instrument they’re reluctant about picking up, I often tell them to think about what they want to do rather than start off worrying how to do it. It appears the same logic is applied here.

I do agree, as you noted, you’ve got to practice a decent amount every day to build your skills and grow without forgetting too much in between down time. That’s not unlike music (or Mandarin and Spanish, which I haven’t practiced in years and have thus forgotten.) I’m glad that the Code Academy assignments allow you to reset them for practicing them further.

—

Regrading our websites, I would want to make a music review site where music is catalogued by genre>artist>album>year. It would be a mix of niche interest, personal and business. I already have some form of cross-page organization in mind in addition to that general hierarchy I just mentioned. The purpose of the website would be to show album art, an artist’s full discography, include references (at the bottom of each page) to similar artists and other purposes. I think it’s somewhat of a wiki page that is more in-depth, adding personal review sections as supplementary elements after straight factual info.

I’ve found the learning curve for programming as an overbearing writer to be both challenging and potentially rewarding.

Of course, there are the similarities in thought processes between copy editors and programmers (e.g., Brian Schlansky using his editing habits to carefully read each line of code). And, as a large portion of the “Rethinking our Thinking” post cleverly and reasonably detailed, coders are in many ways like editors. But copy editors are often the worst enemies of writers.

Some of the 17 rules of Unix Philosophy are anathema to the laws of good writing (Melville, Churchill, etc.). “Clarity is better than cleverness” and “Design for simplicity” to name a few. Having the habit of condensing lines to the bare necessities — and potentially breaking the entire code with a single character out of place — is also frightening to writers, yet common workflow for coders.

What I see as potentially rewarding is the benefit that journalists could gain in learning from programmers. Software languages — like human languages — have developed from Autocode to iOS, and that matters because we as future programmers should know that everything is fluid and able to continually evolve. And although coding often requires linear, step-by-step thinking (similar to the infrastructure of the internet) when compared to writing that is often tangental and more loosely flowing from beginning to end, there is still a progression of thought and purpose for the finished product.

After completing the readings, I still don’t believe that writers are programmers. But I do believe that writers and programmers have the capacity to be journalists. I have faith that the end goal of both draws on some common ground between the diametrically opposing belief systems. When writers use their words and images to tell stories, programmers rely on design and page hierarchy to tell you what’s important. Perhaps, just as there are many forms of writing, a visually appealing article page could be equally as effective in enlightening and entertaining an audience — even when compared to a Shakespearean play? Ah! There’s the rub.