03: Common Misconceptions About Programming

I've been creating programming education courses for about 10 years, and during that time I've seen many students give up because of simple misconceptions and incorrect perceptions of programming as a craft. In this module I explain these misconceptions and the patterns of behavior I see that thwart (or enable) your success.

1: "You Have to Quit Your Job"

The fantasy peddled by many Coding Bootcamps is you quit your job to study full time and after just six months you're making $250k/year at Google. Another similar fantasy peddled by computational education con artists is you can quit your job to study programming full time and then create the next Facebook. What none of these people tell you is the people that can quit their job to study full time are people who already have money or support. You'll hear about someone quitting their job, but they don't tell you how their spouse kept working to pay for their dream, or how that person happened to have plenty of money in savings, wealthy parents, or some other form of golden parachute.

If you don't have a similar support network then there is absolutely no way you can pull off quitting and studying full time. I'm telling you right now do not quit your job. That's a childish fantasy that does not match reality. The reality is you need a job in order to make money to support yourself and your family while you work on this course and quitting your job will cut off that supply of money. The smart thing is to keep working, and adjust your life and work schedule so you can study.

You may be thinking, "It will be so stressful to work a full time job and also try to study full time!" You know what's more stressful? Being thrown out of your house or not being able to buy food because you quit your job thinking you'll be the next Mark Zuckerberg. Having to get up a few hours earlier to study before work is far less stressful than being homeless. In fact, if you aren't willing to give up some of your activities to work on this then how can you be dedicated enough to quit your job and focus on this full time? If you can't sustainably put in 2-4 hours of your own free time every day while working a job then quitting your job isn't magically going to make you more motivated. It'd be better to prove to yourself you're into this by sustaining a 2-4 hours a day coding schedule for at least 6 months before you even think about doing anything drastic.

I'll also admonish you to really go study your business heroes to see if they really are "self made." 90% of the time these supposedly "self made" business types actually had quite a lot of luck and wealthy relatives or connections. If you don't have their similar background and access to the same capital then you're not being realistic about your chances of success when trying to copy their story. In fact, I'll bet you a crisp $100 bill their story is a complete lie anyway and mostly told to investors to get investment. The reality is they had rich parents who loaned them $250k to get "started in their garage" while their spouse worked full time to put food on the table.

2: "You Can Explain Your Thoughts Accurately"

Why do I have to say Big Red Ball and not Red Big Ball? In English this is a rule that every native speaker knows, but we can't really tell you why. English is a messed up homegrown language that stole features from every language it encountered, so the rules are difficult to define. Us English speakers also can't tell you why something is right until we study the subject for years, and even then most of what we might say is just prescriptions on how to write better, not descriptions of the actual rules we use.

Imagine if I asked you to write down all of the rules about "Big Red Ball", and get them so detailed and so correct that I could hand them to anyone and they would be able to create perfect descriptions of objects. You would probably start out thinking, "This is easy. I totally speak and write English." In your mind, your thoughts and how you use English are accurate and you can explain them. Then...you try to explain them.

You would quickly find out you have no idea how you know the rule. You can't even explain the rule to someone else. You would try, and they would quickly find an exception to your rule, and you'd realize you need more rules. People would try to write sentences using your rules and they'd end up writing English that follows your rules, but makes zero sense because you don't know 1000 other rules. You'd have to keep trying your rules, over and over, on thousands of people, constantly refining them until they covered every condition and every unwritten exception. Then you'd have to rewrite these rules so that they were simplified for people who wanted to follow them.

Most people don't need to do this, but as a programmer this is all you're doing. You are describing unsaid intuitive thought processes to such detail that a computer can run them and handle all possible exceptions without failing. What causes beginners problems is they think they know all of the details of their own thoughts, but when they translate those thoughts to code, they quickly figure out they have no idea how their own thoughts work.

A beginner might write this logic:

if it's raining outside or cloudy
  I will take my umbrella

To most people that makes sense, but it is actually ambiguous if you really look at it:

1. If what is raining outside? The clouds? The sky?
2. "or cloudy" what? Cloudy outside? It's just a word sitting there.
3. You will take your umbrella? Where? Outside? Into your closet? To the bathroom? To lunch? Just carry it or use it to block the rain?

These "problems" with your logic are dumb--as most people who speak English can figure out what you mean--but computers are very dumb, and you have to specify everything for a computer. You have to clarify all of your thoughts and cover everything or else the computer will have no idea what you mean. You need to write like this:

If the weather outside is raining or the weather outside is cloudy
  I will take my umbrella with me when I leave to go outside.

This is annoying, but that's how you have to think when you code. You have to assume the computer knows nothing and cannot read your mind. It does not know anything you didn't tell it, so you have to specify everything. The good news is this way of thinking isn't too hard to learn, and JavaScript will usually tell you when it doesn't understand you. The trick is to work on assuming nothing when you think, and taking the time to really think about what the process is when you write code.

During the course I'll show you a consistent process for getting your thoughts organized like this, but this leads to the next misconception.

3: "The Solution is Outside"

For most people the education system has taught them to look outside their self for answers. This is a great strategy about 90% of the time, and even more so with the creation of the internet. You can almost always look up a problem and find reasonably good answers. If you can't find an answer, then you can usually find clues. In school you could ask a teacher, and you might have been encouraged to ask often to confirm you are correct in your answers.

In programming this also works about 80% of the time...if you already know how to code and know what to look for. The problem many beginners have when programming is they don't know what to search for, and 20% of the time there's simply nothing on the internet that will help you with your particular little problem. In programming, you write a large majority of your own problems, and nobody has solved those problems for you yet, so looking for answers outside won't help.

This is all totally normal, but the misconception is that if you can't find an answer, and you don't immediately know the solution, then you are a terrible programmer. This is false because all programmers hit a point in their code where they can't find answers to the problems, and the fun part of programming is diving in to figure out what's going on using your own skills of deduction. Beginners however don't understand this and give up at the first sign of difficulty thinking they're a failure. The truth is, you just have to keep digging for clues in your code--or delete it and try again more slowly--to figure it out.

When you hit an error message or a problem you can't immediately solve, don't give up. The trick is to realize that everything you need to solve the problem is right there. You have the code you wrote, and the entire system there for you to review and search for answers. You can take the whole thing apart piece by piece looking for clues. It's a mystery to solve, so if you run into a problem you can't solve, keep going.

4: "Programming Is Linear"

I see many, many beginners write their code in a linear one-shot fashion:

1. Have random amorphous idea in their head.
2. Start at the top of a .js file and start writing JavaScript.
3. Get to the end after writing a lot of JavaScript, run it once.
4. Get tons of errors, feel like a failure, and give up. You can't code like a real programmer so you will never be one.

The misconception here is that's not how any programmers write code. In fact, that's not how anyone makes something creative. All creative processes are about building and destroying what you built in a continual reshaping of what you're making. It's not linear. Painters don't start at the top and dab tiny dots of paint from left to right like an inkjet printer. They paint in stages, scrape things off, scrape the whole painting off, correct as they go, move things around, and go from general to specific.

Programmers do the same thing. We don't start at the top of a file and write code like a printer. Programming is about slowly and carefully building your idea and translating it to working code. This is a painful process full of errors, and even as a multiple decade veteran programmer I still have to build my code and constantly run it. If I'm still taking my time and constantly running my code, then how can you expect to start at the top and write perfection until the very end?

The actual process most programmers use is something like this:

1. Get ambiguous idea.
2. Explore the idea more as drawings, text, small little test codes, anything to help make it more solid.
3. Write a small little piece of the idea, and run it constantly. Every 2-3 lines of code I run it.
4. Slowly build the idea by writing more and more small pieces that are connected together.
5. Refining what's written as we go, and again, constantly running and testing our code to confirm it's working as we work.

The easiest way to solve this misconception is to follow a simple rule for beginners:

"If I write too much code and it doesn't run, I will delete it and write it again with frequent running/testing as I go."

It's easier to fix mistakes in a few lines of code than in a huge file full of hundreds of lines of code. Remember this as it will save you much frustration in the future.

5: "It Should Be Easy"

I'm not sure why, but there's a particular kind of person who believes that everything they do should be easy, and if it's not easy they give up right away. I usually spot these people when I have a conversation like this:

Student> help! my code doesn't work I can't figure it out! I'll never be
a programmer!
Zed> How long have you been working on it?
Student> LIKE A WHOLE 30 MINUTES! I SUCK!
Zed> I spent 2 days trying to figure out why my server kept crashing and
it was because I spelled "user" as "users".
Student> What?
Zed> Yes, 30 minutes is nothing.  It should take you a long time and be
hard to solve.

This is a summary of a real conversation, and if they simply keep working on the problem for longer than 30 minutes they solve it.

For some reason they've set up this unrealistic expectation of their skill that says they should be good at everything with very little effort. They want to be a "natural" but the reality is most "naturals" were trained from a very early age (and then usually lie about it). Everyone has to work hard, study, and fail frequently to be good at something. Programming is nothing but continuous failures until it works.

Just keep working and trying different possible solutions and assume this process will take longer than 30 minutes. It may take a few days.

Things to Work On

These are the top 5 misconceptions about programming that I see discourage people. If you see yourself falling into one of these patterns just ask yourself why you believe this. Chances are you learned this idea from somewhere, and if you figure out where you'll have an easier time getting rid of the misconception.

I'd also like to point out a small set of tips that will help you:

1. Keep a journal of your progress and keep all of your code. You'll feel overwhelmed like this is impossible, but if you keep a journal you can look back and see how far you've come.
2. Steady progress is better than being a natural genius. Natural geniuses don't exist anyway.
3. RUN. YOUR. CODE. CONSTANTLY.
4. Did you read #3? Read it again. The top thing beginners mess up is not running their code enough.
5. Every error message you get is a lie with a small grain of truth. If you can't figure out what's wrong with a line of code given in an error message, then start looking at the lines above it.
6. Search for every error message online.
7. Try to solve all of your problems yourself before asking for help. You'll need to be able to work independently and won't be able to constantly ask for help. Also, if you want to get good, you have to struggle with solving these problems on your own.

Next Steps

Next I'll show you how to install the required software for your computer so you can really start the course.