Familiarity in Formatting
10 Feb 2022We’re not learning Python anymore
My first experience with coding ever was coding turtles to draw pretty geometric shapes with python from a base level IT class. It was super simple to follow along with, and pretty straightforward after you learn the general functions. Everything from there was just a copy-paste or muscle memory to syntax. Eventually as I switched majors, made Computer Science my main interest, and started to advance in my coding journey with different languages, I struggled to memorize all of the different syntax and formatting that came with writing code. It can be especially hard to memorize when you aren’t continuously practicing how to code either. For some classes, we would learn a concept and then code it in an assignment or example to show that we have “learned it” and then immediately move on to the next concept. It was basically just checking a box. After a coding class ends, we often rarely end up exercising what we just learned in repeated patterns and some of the semantics for all these different coding languages just end up getting tossed out or jumbled in our memory bank.
Although there are only slight variations between these coding languages, it helps to have a formatted guideline that stays relatively the same across the board. A bit of familiarity in new waters makes one more comfortable and willing to dive in right? Now taking a software engineering class, I’m learning to code in Javascript and Underscore using ESLint and Intellij IDEA. You’d think with a name like Javascript and Java they’d be relatively similar to each other, but I found that they’re definitely different. Easier in some ways, harder in others. For example, learning to implement in Underscore (a javascript library that uses new applications of functional programming). Adjusting to Underscore has been interesting.
Seeking the Familiar
I think this is a very human response, but after a while we get adjusted and comfortable to what’s familiar to us. No one ever wants to willingly admit and say that they are stagnant, it’s such an ugly way to put things, right? But unconsciously — and sometimes I’ll catch myself doing this too — fear or more will hold you back and keep you in one place. You’ll find it in the way some people react, “Oh well this is how I’ve always done it,” maybe especially with me being from Hawaii, and living that small island life, a lot of my peers will stay on island and refuse to branch out, it’s not necessarily a bad thing, just an observation that there’s a level of comfort that everyone tends to float in. Our fight or flight response kicks in when that threshold is violated. For me, I will admit, looking at the syntax for Underscore raised a spike of anxiety for me. It wasn’t too bad, definitely simple syntax, in fact it condenses a lot of the code that we write into singular sentences, but I’ve just never seen code formatted with ( _. ) the way it is in Underscore. A lot of the functionality of Underscore is still new and I’m getting used to what each one does. We’re no longer using for-loops or while-loops.
Little Things make Big Things
Stepping outside of these comfort zones that we’ve created for ourselves allows us to learn and grow. How can I use this new functionality to make my coding easier and better? The same goes for Intellij. You could say Visual Studio Code or Eclipse would be an easier coding software to program in, but in learning to struggle and master the skill of a new software, in the long run you’re investing into a better functionality output. Pairing it with the ESLint plugin for code formatting and inspection, it allows us to be conscious and mindful of the little details in coding. I used to hear this a lot from someone who cared a lot about these minute details, because “the little things add up to make the big things.” Someone might look at ESLint and ask, “Well, why does it matter that I need to put a space after this bracket? Why can there only be one newline between code? This all outputs the same thing, with or without this formatting. . .etc.” Well, I can tell you, that since formatting things with ESLint it has also definitely made the readability of my code that much easier. Rather than resorting to looking up syntax, the repeated syntax warnings from ESLint remind me how to format a function, I’m reminded, ‘Oh, this requires a space here,’ or ‘Oh, this requires a new line here.’
Printed in Memory
It’s kind of the same concept with flashcards, muscle memory and repeated practice. You see a warning enough times, you’ll end up memorizing it better too. Another functionality of ESLint that I personally enjoy is that it makes pointing out your mistakes easier. For my fellow coders, I know how frustrating it is to work on a code for hours, and then spend another few hours just trying to debug and find out in the end it was just a syntax error. ESLint even has a feature that can just fix all the errors for you. The green arrow that indicates that your code is formatted well saves that much more time in the debugging, because then you can worry more about the actual function of a code than wasting time trying to figure out if maybe it’s actually a formatting or syntax error.
I think when someone is learning something, an important virtue, for both the teacher and the student is patience. Patience to learn the basics, the foundations, the little details, but also patience while navigating the unfamiliar. Focusing on formatting now, I believe, can help create that beacon of familiarity for other coding languages you learn in the future. It develops good foundational habits.