5 things I had to unlearn before learning how to code

If you’re a new coder there’s a good chance you’ll have to unlearn these things too.

I’ve been learning to code for about a month and a half and have seen tremendous progress in my abilities.

While I’ve definitely had my fair share of struggles with JavaScript itself, I’ve had quite a few more problems when it comes to my approach to coding.

So here are the things I’ve had to unlearn in order to learn how to code.

1. “Don’t just Google it”

Throughout all my years in school there was always this mentality of “don’t just Google it.” Sometimes, teachers and professors would tell my class point blank not to Google things. Other times it was self-imposed. Because I like to make my life harder like that.

So when it came to coding, I was operating under the same mentality.

Even though I knew there was no way to know it all — even though multiple people (my friends, partner, and the Treehouse instructors) — I still tried to barrel ahead without looking things up. I tried to rely solely on memory and notes, and a few logical assumptions. Needless to say that wasn’t conducive to learning.

When it comes to learning to code, there’s no way to retain everything. There is so much information out there: libraries, frameworks, languages, syntax changes and evolves, methods are deprecated. There is just so much out there.

The programming community is built on shared and sharing knowledge and not googling things truly limits your learning.

Lesson: Google everything.

2. Not showing my work

I hated it when teachers said “show your work.”

I mean, if I could solve the equation in my head why did I have to write it out? Why couldn’t I just jot down the answer and be done with it?

Well, there are a number of reasons but when it comes to coding it all boils down to this: You have to tell your program what to do. Literally. Otherwise, it won’t (can’t) do it.

If you want your app to tally a player’s score or you want your website to display only 10 search results per page, you have to tell your program that. Just knowing it in your head won’t make it happen on the screen.

Lesson: Show your work.

3. Not starting small

It can be easy to get wrapped up in the idea of programming an app or building a website — projects that can take hours/weeks/months to complete.

But more often than that there’s a tendency, especially among new coders, to try to start developing two or three steps into the solution, instead of starting at the beginning.

Usually, this isn’t because they don’t think the first step is important, but because they’ve missed it. I know I did that on more than one occasion and it’s all because I figured out the formula I needed internally but didn’t add it to my project (see item #2 on this list).

But the fact is all apps, websites, and etc. start with one line of code.

Lesson: Start as small as possible.

4. Multitasking

When I first started coding, I did this constantly. If I couldn’t get one part of my code to work, I’d switch to another. Then if I couldn’t get that to work, I’d switch to something else or go back to what I’d been working on previously.

I didn’t get most of the things I was working on to work and, if I did, I rarely had an understanding of what I’d done to make it work.

By focusing on one thing at a time, you’ll feel a sense of accomplishment when you finish each part, see how your code interacts, and quickly identify bugs.

Lesson: Focus on one thing. Finish it. Then move on.

5. It’s not me, it’s you

In this situation, the “me” is you (the developer) and the “you” is your code.

On more than one occasion I’ve stared at my text editor, reading through my code trying to figure out why what I expected to happen did not match what actually happened. After about 5 minutes, I’ll realize there was a typo, a flaw in my logic, or that I didn’t call my functions in the right order. (That last one happened just the other day).

Just as I did, it’s easy to assume that your code isn’t working because there’s something wrong with it. But most of the time, it’s not working because of something you — the developer — did.

So learning that you’re the one who made a mistake, not your code, goes a long way in both helping you learn but also when it comes to debugging. Not to mention that one day when you have that job as a developer, owning your mistakes will make you 10 times easier to work with.

Lesson: It’s not your code. It’s you.

I’m not that far into my coding journey and I have a lot to learn. But unlearning these 5 things has made an incredible impact on how I approach coding, as well as my actual ability to write code.

I spend a lot of time thinking about books, writing about life, and learning to code. If you’re interested in following my journey to become a programmer, you can follow me on Medium. If you’re a woman in tech who feels like an imposter: I can relate. Feel free to reach out to me, we can talk tech and help shed our imposter syndrome together.