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.
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.