Epiphanies I had while teaching myself to code

This post originally appeared on Novice No Longer.

It’s been about a year since I decided to teach myself to code. At the time, I had a bachelor’s degree in English, a job in retail, and zero knowledge about programming. I’d had minute brushes with coding in the past but hadn’t even thought about math or coding since high school.

The impetus for learning to code came from my growing addiction to Hacker News. I, too, wanted to build cool things and understand how web apps and programs worked. I wanted to have an app in the App Store, dammit. I wanted to start a business.

But, for someone who couldn’t tell JavaScript from Common Lisp, I had no idea where to start.

Thus, I began my journey into the world of code. Often flailing, unsure, and guessing. I’ve come a long way since my failed attempts at learning to code lead to hiring a developer to get my apps in the App Store. I’ve had numerous coding epiphanies along the way and there were many things I wish I had known starting out. If you, too, are teaching yourself to code, or want to begin learning to program, hopefully some of the things I’ve learned can help you out, too.

Computer science/coding isn’t about the language

I remember hearing that a computer science degree doesn’t teach you how to program, it teaches you how to think. Every developer is self-taught; computer science just gives one the tools to easily learn programming languages. I don’t have a Computer Science degree, so I can’t fully attest to the validity of these claims, but from what I’ve experienced so far, there’s no better way to explain this field.

When I first decided to learn to code, choosing a language was a great dilemma for me. In my mind, my plan was: 1) Choose a language, 2) Get a book on this language, 3) Finish book, 4) KNOW HOW TO CODE.

This is not how to learn to code if you don’t have any prior programming experience[1. I suppose, technically, this is one possible path one can take. But it’s, arguably, not the most optimal path nor the best way to think about learning to program if you’re exploring this field for the first time.]. As a result, I found myself getting to chapter 2 or 3 in a book before becoming completely lost, deciding to pick up a different language, and starting all over again. I dabbled in PHP, Javascript, Ruby, Python, and Objective-C by following this flawed method. And, though I do advocate trying numerous different languages, this four-step plan put me in the wrong (read: un-optimized) mindset when first picking up each of these languages.

Not only was I frustrated that I couldn’t get past chapter 2 or 3, but each of these books started the exact same way. I was learning about variables, for loops, while loops, switches, and arrays over and over again when I really wanted to learn something new, something to get me past the bump in the road I had hit.

Eventually I had a realization: learning to code isn’t about learning a language. Learning a for loop is like learning a Phillips head screwdriver. A hardware store may have a wall covered with different types of Phillips head screwdrivers, but the real goal is to learn how, when, and why to use this specific tool.

Try a bunch of different languages

The first language I tried was Javascript with Codecademy. This proved to be a fantastic tool and resource, and was a fantastic way to start my journey. But soon I became frustrated. I had no idea how math, numbers, loops, and switches related to what I saw on websites. I didn’t know how assigning 3 to a variable and adding another variable could ever result in, say, a button on a website changing color.

With the help of an online coding mentor (who independently reached out to me because I blogged about starting to learn to code) I brushed up on HTML and CSS[2. So much had changed since 2002!] and learned about jQuery and the DOM. This is when I learned the definition of framework and was able to code a very basic calculator app.

It was then that I realized that I didn’t want to do front-end development and decided to switch to Ruby on Rails, which I constantly heard was a great language for beginners (although I didn’t quite know what that meant). I started working through the Rails Tutorial by Michael Hartl.

I spent a particularly long time on the Rails-flavored Ruby chapter, which I found particularly interesting because of my Javascript background. Learning Ruby was a fantastic way to pinpoint the important parts of Javascript. It helped me separate concepts from language quirks. During this time I also dabbled a little bit with Google’s Python class and had the same experience.

Playing with multiple languages didn’t confuse me like I thought it would. Instead, it helped me understand core concepts. When I finally decided that Objective-C was the first language I wanted to truly learn (a decision I made nearly 10 months after first completing a Codecademy lesson) I had a firm grasp on the concepts of variables and loops. I was able to appreciate static versus dynamic typing and understand why Objective-C was static[3. Except for the id variable.]. Without dabbling in all those other languages, these concepts would have been much harder.

Do the exercises

Writing code isn’t a requirement when you’re learning from books, tutorials, and videos. Codecademy is different because it forces you to write code—that’s what makes it great. It’s easy to read a chapter or watch a video, think you understand a concept, and then move on. But understanding the concept and performing the exercises are two different things.

With the Rails tutorial, physically typing and executing the code was part of the natural process of working through each chapter. I would go through each section and perform all the motions even if I didn’t understand what I was doing. The next day, I’d re-read the entire chapter extremely slowly. If I didn’t understand one sentence, I’d re-read it, scroll through examples, and research concepts until I did understand. Sometimes I’d go through the same chapter numerous times in this way: re-reading until I was able to read and understand each paragraph at a normal pace.

With books, it’s even easier to skip doing the actual work since it’s easy to skip over the exercises at the end of a section and just move on to the next chapter. Don’t skip the exercises.

Actually writing and running the code might seem like a small step, but it’s really at the crux of learning a language. Troubleshooting will teach you things you didn’t even realize you didn’t know and will often have you flipping back through the chapter to double-check small details or go over a topic you thought you understood.

Even if you read an exercise and think you know exactly how to do it, type it out anyway.

You already know the concepts

Understanding code concepts and algorithms[4. Algorithms are, simply put, a process or set of rules to be followed.] is actually something you’ve been doing your entire life. At first, learning a programming language may seem akin learning magic, but it’s nothing more than learning how to think and speak to a machine. In the same way that verbal language communicates your thoughts to others, programming language is a way to input your thoughts into a computer.

Before I even wanted to learn to code I was writing programs. I lived in the Prospect Lefferts Gardens neighborhood in Brooklyn for about four years. There were numerous ways to get to work from my apartment. I figured out two different ways to get to work, on two different trains. The first train was close to my apartment but I had to change trains halfway through the commute and the other train was a longer walk from my apartment but the ride was shorter and didn’t involve a train change.

In the morning, I’d run a “program” in my head, inputting variables such as weather, time, and my mood, and returning my decision about which train to take. It was simple if else logic that determined whether to I took on the 2 or the Q train.

Soon, I became obsessed with optimizing my commute based on different variables. I studied the subway map, tried other trains, checked time tables. By the time I moved out of that apartment, I could have written an essay about how to get from Prospect Lefferts Gardens to NoHo in Manhattan. Any time someone asked me “What train do you take?” I had to stop myself from rambling on and on about my options.

The tactics used to calculate the best route are the same concepts used in programming. In conversation, I might say, “I change trains at the Brooklyn Bridge station,” whereas in coding I’d write if (station == "Brooklyn Bridge") { change trains }. It’s the same concept, just expressed using the tool of an if statement rather than the tool of the English language.

In coding, my daily commute instructions would be broken into minute pieces, even more so than if I was giving verbal directions. For example, maybe I’d never consciously think to “mind the gap” when getting on and off the train. Some programming languages will automatically mind the gap, others will need to be explicitly told. Learning to code is about understanding that minding the gap is an intricate part of your commute and then figuring out how to properly communicate this information using the tools provided in the language you’re using.

You’re learning even if you feel like you’re not

I often felt like I was moving in slow motion when learning to code. I even felt like I was taking steps backwards whenever I switched to a different language since I thought I’d be back at square one. That’s not the case. Just keep going, keep reading, and keep pushing forward amid the fog.

Whenever I felt like I was stuck, I’d re-read my old blog posts where I discussed code or I’d return to previously read tutorials and books. I’d remember my mindset when I first mucked my way though, and that’s when I’d realize how far I’d actually come. Coding knowledge builds in layers, and sometimes the layers are so thin it doesn’t feel like there’s anything added. But soon enough, the slivers add up to significant mass.

Teaching myself to code has led me to the believe that anyone can learn to code. It’s not about the language, or math, or syntax. These are just tools. It’s about thinking, and the thinking will come in time. Just keep going and you’ll get there.