There are a handful of extremely common mistakes that you should never do while learning to code. These pitfalls can make it incredibly difficult to gain momentum early in the process. So if you’re just starting out, remember that these common missteps. 

1. Endlessly research technologies without spending time actually writing code.

Starting out is super intimidating. What if you pick the wrong programming language? Web framework? Or database?  Experts often disagree about the best approach, so the research phase can feel like an echo-chamber of differing opinions.

A reader recently commented on one of my Medium posts talking about this idea:

“My ‘Research Phase’ lasted an entire year! I read about coding a lot, mostly JavaScript. Without actually getting any coding done.

I found that by coding for an hour a day I learned more in weeks than I had in an entire year.

Now I’m wishing I would have been writing code this entire time vs. just reading about it. Better now than never though, I love it and I aspire to be a computer programmer at any cost.”

– @rico0420002 on medium.

The fact is: you can’t learn to code by reading about it. The only way to learn is by actually coding. Don’t worry about learning the wrong thing. Any language that you pick will at least help you learn the concepts central to programming. Skills like naming variables, defining functions and breaking down complex problems apply to all programming languages. So it’s not a big deal where you start.

Once you master one language, picking up a second language is much easier. So don’t let an analysis paralysis prevent you from ever starting.

2. Treat learning to code like studying for a test.

Spending time memorizing details will prevent you from understanding the bigger picture ideas that actually matter. In programming, you’re not going to be quizzed. You likely won’t find yourself in a jeopardy-like situation where you need to come up with the answer without using any resources.

Instead, you’ll almost always be able to lean on resources to find the solution. Using Google to find an answer isn’t cheating. Neither is looking at code that you’ve written in the past.

With code, learning where to look to cheat is more important than having the answer memorized.

3. Let problems in your code pile up endlessly without checking if it’s actually working.

The best developers are skeptics. They constantly check to make sure that their code actually is doing what they think it should be doing. This means they take a few minutes to double and triple check before moving on to the next thing.

Lots of beginners make endless changes to their code and expect it to miraculously work right away. The problem with this approach is that it stacks one problem on top of another, and it becomes difficult to figure what went wrong.

It’s far easier to untangle an application with one small problem than to fix an application with 10 connected problems.

So if you want to level up as a developer, be a skeptic.

4. Learn to code in isolation.

The best programmers embrace their community. Most cities have multiple in-person meetup events for programming, and there are awesome online communities like Reddit and StackOverflow.

Beginners often feel apprehensive about attending events or commenting on open online communities. The imposter syndrome is real. But if you’re a beginner, know that the rest of the programming community wants to lift you up as a developer. That’s just  the approach that the majority of experienced developers take. They’re a very collaborative bunch.

Never underestimate the importance of building relationships with other developers. Talking about code and collaborating on projects is one of the best ways to improve and build confidence.

5. Get too emotional early on in the programming journey.

You’re going to see error messages on your journey to becoming a programmer. Probably lots of them.  Screwing up is normal, and you need to have the attitude that it’s ok to make mistakes.

As you see more and more error messages, you’ll eventually start to become better and better at deciphering what they mean and how they can help you solve problems. Learning how to fix problems and read error messages is a skill that takes time to learn. And it doesn’t come naturally to most people.

Know that seeing an error message on the screen doesn’t mean you’re a bad programmer.  Instead, it means that you’ve typed the incorrect sequence of symbols into a text editor. This is fixable by just typing the right ones in the text editor!

6. Think you need 5 different monitors to learn to code.

Contrary to what Hollywood might tell you, you don’t need an insane external monitor setup to learn to code. You don’t even need a super powerful computer to write most computer programs. I write most of my code from a fairly old MacBook Air, which is more than capable of building most modern web applications.

So, so unnecessary
So, so unnecessary

The computer you own right now is probably good enough to use to start programming.  So start with that one first, and always know that you can upgrade your programming environment later. You’re not making a major commitment when you start programming.  Don’t overthink it.

7. Overlook the difference between a capital letter and a lowercase letter.

In programming, the details matter. Even small details- like the difference between a capital and lowercase letter. Pay close attention to things like:

  • Singular vs. plural is different
  • The number 0 is different than the letter O
  • A dash is different than an underscore.

It’s important to get used to noticing subtle differences between similar symbols.

ultimate guide to programming languages

8. Ask for help the wrong way

At some point in your coding journey, you’re going to need to ask for help. Everybody does. And if you ask a question in the right, constructive way, you’ll often get a clear concise answer. But if you don’t phrase your question in the right way, you’ll often find the experience pretty frustrating.

There are 4 things that you can do to make sure that you’re asking for help in the right way:

  • Overcommunicate details that you see.  Feel free to include additional details someone might want to know, but also might not be needed.
  • Explain exactly what you think should be happening.
  • Explain exactly what is actually happening.
  • Explain why you think it should be working differently.

Dozens of times I have started drafting up a StackOverflow post and figured out a solution to the problem I was asking about in the process of going through these 4 steps. It makes you think about problems in a holistic way.

This behavior is known as “rubber ducking”, and it’s the tactic computer programmers use to ask a question to a toy duck on their desk to figure out a problem.

9. Think you need to be a math genius to be any good at programming.

Having a decent grasp on high school algebra can be helpful, but the problem-solving skills that you need for programming are mostly different than the skills you need for mathematics. If you’re not a “math person” or failed Calculus in college, you probably still have most of the math skills you need (and if you don’t, you’ll be able to pick them up pretty quickly).

10. Refuse to change bad code.

Every great programmer has written a lot of bad code.  So if you’re just starting to learn, you need to be open to changing your code to get it to a better state. You do this by learning different and more effective ways to solve problems.

When lifting weights at the gym, there is a certain correct “form” for each type of exercise. The better your form, the more effective the workout. Code is similar. You should always audit your code and see if you could write it in a more effective way.

When starting out, it’s ok to make mistakes. Just know that you want to always be thinking about how you could improve your code.

11. Only value the minutes you spend physically typing.

Typing code is part of programming. But it’s you might also need to spend time researching/reading to teach yourself new programming concepts or figure out a solution. This stuff still counts.

A typical day for a programmer isn’t 100% just endlessly typing on a keyboard, producing code and solving problems. Programmers spend a lot of time researching technical topics, testing things out, experimenting with applications, and reading log files too.

12. Try to understand something before moving on to the next thing.

Computers are built up of many levels, so understanding every level at 100% is generally impossible.  

For example, if you’re learning ruby, you’d probably want to learn how to define methods.  But if you wanted to know “how come it works like that”, you’d need to dig into the ruby source code, which is written in C, a different programming language. In this example, it could mean that to fully understand ruby you’d need to understand C too. But in reality, this isn’t the case.

Instead, in programming, it’s ok to accept the facts as you learn them. You don’t need to go down every rabbit hole in search of the answer to “how come it’s like that?”  This is a tough habit to break since you’ve been conditioned to think that you need to know every answer. But it’s not the approach that you should be taking with learning to code.

13. Expect that there will be a time where you fully understand all aspects of programming.

Joel Spolsky coined the term “duct-tape programmer,” which does an amazing job of describing how software is actually built.

Most people think about software being built like a rocketship…being expertly designed, crafted, manufactured and then ultimately launched. In reality, building software is more like repairing a speeding go-kart as it careens down a hill, using only some duct tape and WD40.

Don’t let unreal expectations of how the real world works cloud your judgment. You might feel like you have no idea what you’re doing sometimes. And that’s ok.

14. Give up right before change is about to happen.

Learning to code (especially to the point where you can switch careers) is a lot of work.So the worst thing you can do is give up right before you’re about to see results. It takes discipline, time and a lot of effort to achieve your goals. Don’t make the mistake of almost enough work to get where you want to be.

If you avoid these 14 common pitfalls, you’ll be in great shape with your coding journey.  So what are you waiting for? It’s never been a better time to start writing your first lines of code!

Ready to start coding? We’re giving away the first 2 weeks our online software engineering program for free. You can sign up here: free intro course.

AuthorKen Mazaika

Ken Mazaika is the CTO and co-founder at Firehose. Previously, he was a tech lead at WHERE.com (acquired by PayPal) and a member of the PayPal/eBay development team in Boston.

6 replies on “The 14 Things You Should Never Do While Learning To Code

  1. I appreciate articles like this, though am bummed that some of the things are beyond me. Working full time in industries that have nothing to do with coding, and not having the funds for a bootcamp like this leads to 3-4 hours a day max and weekends, and finding coding ‘companions’ to keep me encouraged can be a pain.

    One suggestion I have is that if you get burnt out on something, or ‘stuck’ – move to something else for a while. For instance, I have a few ruby on rails projects (though I’m still learning) in my git repository that are mostly back end work because my front end skills are weak. I was sort of stuck / ‘blah’ about them – so I took two weeks off of them and looked at a different online avenue (that’s free) to refresh HTML / CSS and ‘re-awaken’ my javascript/jQuery muscles.

    Sometimes taking a break is as important as spending hours coding

  2. Nice–really liked the quick presentation of all the ideas. I probably violate 9-10 of these rule daily but I’m following the 14 step process.. 🙂

  3. I recommend you to rephrase the rubber duck debugging.
    It’s based on reading every line of code from the source and explaining their actions, it helps to remedy any typos or wrong function usages.

  4. Interesting thought about writing more effective code. Love it. But as a beginning programmer I am often wondering what is more effective.

    Just seeing the difference between MyClass and myClassImplementation, which is probably #0 on the list – what makes for effective programming solutions? One that works for me, or best practices (I am stumped at the use of Singletons in Android for instance – the code works for me, but I somehow feel that I am using them inappropriately)

    So what makes for the 10 most basic effective code practices? Start with trusting Lint, and work from there – probably not. Then I am reading about test driven development and the importance of seperating true Java from Android specific code – but this implies a number of patterns I am not that familiar with.

    In short, I struggle with moving from a ‘sophisticated’ hello world type of programming, that will make it to a working app, to a structured ‘efficient’ code base. Any thoughts / sources for this?

Leave a Reply

Your email address will not be published. Required fields are marked *