💾 Archived View for tilde.team › ~mathpunk › gemlog › 2023 › learning.gmi captured on 2023-05-24 at 19:35:48. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
A lot of people think I'm good at math because I was born with some innate ability to parse it. I find this view incorrect, ignorant, and often, downright offensive. I'm not going to go into detail surrounding my beliefs about math and ability just yet, but the short version is: I sucked at math in school. I had to retake grade twelve because I needed a math credit to graduate, and didn't have one because I failed math. I quite literally slept through my grade twelve physics exam because I knew I would fail, but didn't want to get in trouble for not going. So I showed up to the exam hall, put my head on my desk, and napped for three hours.
I'm good at math now because I spent a solid four years developing an elaborate toolkit of study techniques that work for me, as well as actively applying effort to shift my mindset from one of "you're either good at math or bad at it" to "the first step to being good at math is being gleefully, unabashedly bad at math." I'm quite proud of this toolkit, and eager to share it with those who ask. However, in my quest to learn various things such as coding, navigating a computer from the command line alone, and general facts about how a computer works on low levels, I've found this toolkit suddenly lacking.
I believe the reason for this has to do with something I call the Golden Rule Of Learning: you only learn to do something you actively keep doing. For example, you can learn a lot about woodworking by reading books about woodworking. In fact, that's quite a good place to start, as you should probably know some things about wood, tools, and safety before you start messing around in the shop. At the end of the day, though, if ALL you've done is read about woodworking, you're not a woodworker, you're someone who knows a lot about woodworking.
Mathematics is a peculiar subject in that it happens in your head. Quite literally, thinking about math counts as doing math. Sure, it's important to do mathematics on paper or chalkboard, but those funny symbols are merely a tool we use to make thinking about numbers easier. It's an externalization of our memories and of mathematical processes, in much the same way that a to-do list is an externalization of tasks - the list remembers, so you don't have to. Thus the toolkit of study strategies I've developed often looks, to an outsider, as though I'm just wandering around, staring at cards on my phone, mumbling to myself about numbers. I do actively practice on the chalkboard, of course, but in my experience that's only part of the story.
Learning to navigate the computer through the terminal is a bit different, because you're not navigating something that exists in your head, you're navigating something that exists on the computer. Thus, thinking about using the terminal isn't the same as using the terminal. Coding is the same: it doesn't happen in your head, it happens on the computer. Thus, thinking about coding isn't the same as coding.
That's not to say that thinking about those things will get you nowhere: you have to have some kind of mental model of the situation in order to process it and know what to do. As in the woodworking example, reading about the process is often a necessary starting point. Unix operating systems have the wonderful little quality of being able to look up "man <program>," which will direct you to the manual page for the specified program, including terminal commands. Help pages such as --help or -h are often built into the programs themselves. Coming from windows, where everything important is hidden behind several layers of fake menus, and the operating system is dead set on not telling you what things are, this change was incredible. However, to make use of this function for any given program, you have to know the program exists, first. Thus, many "command line for beginners" tutorials exist online.
The same is true of programming: you can't just sit down, pick a language, and make something. You have to sit down, pick a language, pick something to make, understand what kinds of building blocks need to go into making that something, and then look up how to accomplish those building blocks in the chosen language. At least, that's how I did it for my first couple projects. It was fun, and for simple applications it went well, but I quickly found myself running to a wall: not knowing what I didn't know how to do. Not knowing about important programming concepts and ideas, and not knowing that I don't know about them.
Even now, people talk about different kinds of languages, like object-oriented languages, functional languages, etc, and I don't know what the hell the difference is, because I just don't have the experience yet. I've come to understand that I want to make a more serious study of coding, and I've come to realize that accomplishing that is going to require developing a whole new toolkit of study strategies. I tried doing it the same way I do math, and that just doesn't work.
I rely quite heavily on flash cards in my study of mathematics. Spaced reptition is a wonderful thing, and I strongly recommend looking it up if you don't know what that is. I make cards for concepts, vocabulary (ex "what is a subtrahend?" or "what's the term for the second number in a subtraction problem?"), general techniques (ex "how do you solve a quadratic equation by completeing the square?"), and example problems (ex "solve this quadratic equation by completing the square.") As a daily practice, I'd honestly say that the flash cards count for at least 70% of my learning. Especially the example question cards - which I aim to do in my head, but do on the chalkboard if I can't. Only after I've mastered the flash cards for a certain topic or technique do I go through the practice problems on paper, and even then, I compare my solutions to the answer key, mark anything I did wrong, and then make flash cards asking me to explain why it's wrong.
Coding is much harder to learn with flash cards alone. You can create special kinds of flash cards which ask you to type in a multi-line answer, and then compares what you've typed to the solution. This works quite well for small blocks of code that do simple things. You can use regular old flash cards for basic concepts like "what is a conditional?" This works splendidly for developing a foundation, but then you come to the task of putting that foundation to use, and that's when things get more challenging. I've failed to make this part work with flash cards, and I've come to understand that my reliance on them in this case is a problem. Remember the golden rule. Flash cards work wonderfully for learning new concepts, vocabulary, commands and keyboard shortcuts, and even small blocks of code, but at the end of the day, there's a certain art to putting all of that together into a much larger project.
At this point, I have to admit to myself that the only way to learn to use the terminal is to just use the terminal - cut myself off from the GUI entirely and live with it until it stops being hard. This is actually quite similar to the process of learning a new language! One of the major hurdles new speakers face is that words and grammar in their new language come to them slowly and with much effort, whereas their native language is effortless and quick. Thus, unless something is forcing you to use the new language, most people just default to their native tongue. Since they're not using the new language, they don't learn it, and it stays hard, which causes them to use it less, which creates a whole cycle that ends with "not knowing a new language." Whatever methods you use to study and learn, you eventually get to the point where you must institute a "use the new language" rule.
Similarly, the only way to learn to code, really code, is to just code things. Put those building blocks together into something, it doesn't really matter what, and it doesn't matter if it sucks. What matters is you did it, and you can LEARN from the parts that suck. Coding is an active practice, it seems. One that I'll probably practice a lot, because frankly, it's quite fun!
Thus, my new, vague idea for how I'm going to learn to code: find resources, read through them, make flash cards for new ideas, and small blocks of code, then just pick something to code and code it. I expect that the flash cards will account for maybe 30% of my learning, and actually coding, all the rest.