We built a house this week

This week was the first week to delve into the first exercise of coding and learning more about HTML. I really enjoyed the exercise and the steps I took to create the final outcomes. It was a little frustrating in the beginning to get something wrong because I forgot to add a comma or a “>”. Then I came to realize that every single symbol, letter, and space matter — which is crucial in our field of work — and the importance of attention to details in coding. Also, the organization and the neatness of the code and the spaces used are essential to the final product. I am very excited to get started with CSS because I am really interested in developing more knowledge about design, which is as important — if not more important — than the content.

One of the readings shows a great analogy of building a website and building a house. The analogy helped me understand the layers of work that go into putting together a house apply in the same way we put together pieces to have the final product of a website. This understanding of structure helps journalists in laying out their work and creating that final piece of work.

I found it most interesting to learn more about the browser’s web inspector. We started the exercise in class but I got more into it this week with the readings. I was playing around with different pages and looking at the HTML code. I found it very helpful that you can hover over the code and it will highlight on the website to show you where it is. I am also fascinated by the back-end work of websites.

I am excited to be learning more about the various structures of a website in the next few weeks and see how these are out together to create the final product.

Learning the basics to code

Coding is an important skill more than ever today. It seems to be a skill employers are looking for more from aspiring journalists today. Learning the basics to it today reminded me of learning how to do different math problems back in high school or college. Not because the basics to coding are as complex, but because the process of learning of them is similar. Learning how to do a math problem usually starts by watching the teacher complete a similar problem on the board. Often, you will follow along and understand the steps the teacher is taking, nodding along as the teacher arrives to the answer. But, once you sit down to do a problem yourself, it is impossible to evaluate how well you grasp the material. Without the teacher’s help, you’ll come to understand what confuses you or what steps you’re forgetting.

Similarly, when I was going through the Codecademy exercises, there were times when I would run into trouble and use their “show me a hint” feature, which was usually helpful. But if I was still stuck, I eventually noticed that you could ask for the solution. While I appreciated that feature when I was stuck, I also think it offered a bit of false comfort. I could nod along and tell myself I just had a minor error and *basically* had everything right, that is not actually the case.

With coding, minor mistakes have enormous consequences. Or so it seems to a beginner. Forgetting to close a tag or include a quotation mark can make the difference between the code functioning or not. As we go along, I am trying to figure out the best way to learn through Codecademy — when to struggle with the code and when to ask for a hint, or when to struggle with the code and when to ask for the answer. Moving to the next slide was helpful in itself because, just like a math problem, sometimes you need to just look at a new problem.

My main takeaways from this week’s readings were simplistic descriptions and analogies by Mindy McAdams on programming. Her conversational approach to programming and code were particularly refreshing and easy to grasp. The next article and its Website=House analogy and it’s picturesque slides made it more comprehensible. Also the introductions of elements, attributes and structure of tags (open <p> and closed </p> tags) and how the concept can be related to our everyday lives was so helpful.

I think the most abusive tool for me this week was the web inspector. I have umpteen times checked and changed the HTML of several websites just to see how what will happen and it was a pretty cool experience :). Sarah disagrees lol. Codecademy’s split screen for instructions, coding and display shows in real time how the tag hierarchy relates to each other and how a glitch in the arrangement can alter the whole hierarchy. Their website is beginner-friendly, with hints to help you along the way should you get stuck on an exercise. GitHub seem pretty straight forward with the creation of a repository and committing to projects. I hope to explore and learn more about its operations as the course progresses in the weeks ahead.

 

Why is the web inspector editable?

The thought of someone sitting in their home rewriting the headline on the front page of a newspaper makes me cringe. Why then, is it possible for me to go to Sir Ian McKellen’s official webpage and change his background image to that of a cat in a turkey costume?

It’s obvious that the web inspector tool is useful for learning how the building bocks of code and style interact. I can also understand that it may be helpful to inspect the code of a website in order to debug it, or to be sure that it doesn’t contain malicious material. But I can’t think of a lot of reasons why it should be editable to the point of replacing McKellen’s face with Turkey Cat’s.

Regardless of the reason, it reveals a few things about the personality of web development, and perhaps of web developers themselves: they are tinkerers. In using Codecademy for the first time, I was reminded of how genuinely rewarding it is to achieve tiny victories in code. If you’re not de-bugging to figure out a past mistake, you’re often pre-bugging to see if (maybe) you can get something right the first time. Because of this, it’s important to break the code components (and the expected behavior) into its smallest unit.

For that reason, I’m also excited to begin becoming familiar with GitHub, which operates a bit like track changes for large pieces of code. With each small unit of code and expected behavior, new opportunities for error and unexpected outcome are introduced. Thus, the ability to isolate small changes and to keep a clear record of edits over time is extremely valuable.

But I’m still not totally convinced about the web inspector tool…

Music in the key of code

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.

Learning Modules on Codecademy

For this week’s module, I want to reflect in more detail about my experiences on Codecademy. Just to mention, even after the readings I still did not know what to anticipate for the actual activities and lessons.

First off, I liked the format and method that Codecademy used to teach HTML. I felt like the breakdown of lessons into different segments kept relevant and more advanced information lumped together, which made it feel more approachable and manageable. Also, viewing everything side by side in a single window was awesome! Seeing the detailed instructions that included pictures, the input area and the coded results all in one look made it easier to learn. I utilized the “Show Solution” option after two failed attempts and it corrected my mistake. This allowed me to go through the text and see the difference between what I had input and what was needed to follow the instructions. Information checking in the form of a quiz was beneficial to reinforce some of the new information I learned.

I had learned some HTML in elementary school when we made our own webpages through HTML, so a lot of the tags and attributes came back to me easily. However, I did have difficulty making the unordered lists and ordered lists appear with bullets or numbers. I will just have to keep working on it.

Week 0

When overviewing the article going over some of the more prominent coding languages throughout the decades, it made even more apparent my lack of previous experience with web development. The only one I had recognized by name was Java. More than anything, it was just interesting to see the coding languages evolve throughout the years alongside technology that precedes and coincides with the gradual evolution of the web and internet. I was most surprised that different companies kept developing and expanding existing technology from other companies in a competitive sort of manner, as opposed to the same companies redesigning their own information. As a millennial, older people are always telling you that you’re very lucky and fortunate to grow up with the internet and all these capabilities due to technology. I did not know previously what exact year “The Web” was born, and it is slightly mind-blowing to learn that it was created right before I was born.

Another portion of the reading I enjoyed was part two of computational thinking and journalism. Specifically, when there was a quote regarding comparing everyday actions and computational actions. Comparing buying your own set of skis instead of renting is comparable to online algorithms.

Journalists and programmers

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.

Mindset and Re-thinking

When reading through the progression of programming languages, I had heard of many of them but never knew what they were or that there were even different programming languages. Though that reading outlines the key traits of each programming language, it was difficult for me to conceptualize without actually seeing them in action. The tree connecting the different programming languages, other than signifying when each was created, wasn’t too helpful in understanding the relation between them either.  That is one reason why it was difficult to know which of the programming languages I’m most interested in learning about, as I do not fully understand the differences and pros and cons of each.

Your blog post on mindset and thinking and how they relate to each other was the most interesting of our readings for me. Having a psychology background from underground, I’m reading a book right now that is actually called Mindset, based on research by Carol Dweck. Without getting too sidetracked, her research deals with how your mindset affects different outcomes in your life. More specifically, people with fixed mindsets tend to view their abilities as unchanging, while people with growth mindsets view their abilities as malleable. Perhaps unsurprisingly, people who view their abilities — whether it is academic or athletic or whatever else — as malleable find more success. For example, someone who figures they just are not a math person will struggle with math. Whereas someone who may not be very good at math, but who thinks he or she can improve, will often do better.

And yet, almost subconsciously, I’ve always had an intimidation of coding and programming. In the same way that some people (wrongly) think they are simply not cut out to do math, I never even entertained the idea of coding because I figured you had to be a real computer person to get good at it. Which is why the most comforting and encouraging thing to hear last night was that Greg did not have any sort of coding background either.

Metaphor is key

I’ve never been great at left-brain thinking — math especially. Reporters are notoriously bad at math, so that was one more thing that helped me fit into this profession.

But the further removed I’ve become from the feeling of stressful confusion that dominated my experience in math and other classes that generally served as precursors for those who went into computer science careers, the more interested I’ve become in the prospect of learning code. Computers aren’t going away.

Getting past the jargon of programming will be a huge hurdle for me. I love deciphering jargon — good journalism writing is being able to cut through jargon and clearly explain concepts to readers — but up until I really understand a concept, it’s difficult for me to connect the dots for myself, let alone readers. That’s why Greg Linch’s post on computational thinking was so helpful.

Specifically this passage, from Jeannette Wing’s article that Greg pulls is very helpful for getting in the right frame of mind:

“When your daughter goes to school in the morning, she puts in her backpack the things she needs for the day; that’s prefetching and caching. When your son loses his mittens, you suggest he retrace his steps; that’s backtracking. At what point do you stop renting skis and buy yourself a pair?; that’s online algorithms. Which line do you stand in at the supermarket?; that’s performance modeling for multi-server systems. Why does your telephone still work during a power outage?; that’s independence of failure and redundancy in design…”

Metaphors like these will greatly help me de-mystify the definitely mystifying world of computer programming and instill some much-needed confidence when I’m tackling topics like this.

I also felt super mellowed out when reading the Zen of Python post. Many of these mantras work for life.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.

Especially in regards to the “explicit is better than implicit” piece, I’m getting a sense that writing code is a bit like doing the work of an observant reporter — one who shows rather than tells — but it’s even more akin to writing a screenplay. When doing screenplay writing, every action is clearly denoted and explicitly stated. Actors in a horror never “feel scared” in a screenplay. They start to sweat. They clench their fists. They dart their eyes around. Their intention and thoughts are only conveyed through action.

It’s a very different way to think about writing than what many of us are used to, but learning it has helped my journalistic writing.