The 5 Hardest Things about Learning to Code (2024)

Learning to code is a roller coaster ride. You can have incredible highs figuring out that error message, async programming finally clicking, finishing that project. And there can be incredible lows coding for hours without making progress, losing motivation, changing your learning plan for the umpteenth time.

Here are five of the toughest parts about learning to code and what you can do to not let them get you down.

When you are first starting to learn how to code, developing a plan can be intoxicating. You’re excited about this new chapter in your life. You’re surprised that you hadn’t thought to do this earlier. You start googling to find out how other people are learning to code.

You soon realize, however, that developing a plan is daunting in and of itself. There’s CS50, freecodecamp, udemy, scrimba, the odin project, open source university, dev100 let alone deciding whether or not you want to do a coding bootcamp! Oh, and you also need to decide what type of coding you want to learn and what language to start with.

This can all be scary for sure. But you can take solace in the fact that mostly it doesn’t matter. The best plan is the one that you won’t quit. This is one reason why bootcamps with upfront costs still work: if you pay thousands of dollars, then the cost of quitting is now very high.

But there are other ways to make sure that you don’t quit.

My favorite one is #100DaysOfCode. The idea is that you code for 100 days in a row. You don’t have to code a lot every day, but you have to do something somewhat coding related every one of those 100 days. Once you get going on #100DaysOfCode, then you don’t want to break the streak! It’s so simple, but it worked wonders for me.

Applying to your first job is scary because it always feels like you are so far away from someone being willing to pay you for your coding. Putting yourself out there and marketing yourself as well as your coding skills seems like a big step. It’s also scary because most likely you will receive a lot of rejection. And rejection sucks.

If you can mentally prepare yourself for this rejection, applying early and often will accelerate your journey. You will quickly learn what is working and what isn’t, and you find out what areas you need to work on.

Kylo Robinson on Code Newbies podcast said it best:

It only dawned on me when I started interviewing for jobs and saying that I knew JavaScript that I realized that I really really didn’t know it

Just know that you are not alone, everyone feels apprehension applying to their first job!

It is surprisingly difficult to separate good learning materials from bad learning materials. Also, what can be good for you early on in your journey can become useless later.

You can follow a tutorial on youtube that walks you through how to create a Twitter clone, and by the end you think “Wow I just made Twitter!”. Except for the fact that if you tried to do something similar from scratch on your own it would be impossible. Even if you are trying to be acutely aware of this phenomenon, it can get you. As you’re following along with the tutorial, each step seems logical and straightforward when building off of the previous step, but you look back 5 steps and realize that there’s no way that you could have made those connections.

That very same tutorial, however, could be useful early on in your journey when you are still exploring what is possible for you. Many tutorials are code candy, enticing but ultimately not good for you.

One way to fight tutorial hell is to reflect on your progress frequently. I used the Github version of #100DaysOfCode to regularly journal my progress in a way that was more introspective than if I were to tweet it out to the world. Another way is to know what it feels like to learn — Learning How To Learn is a fantastic free course that helps you tackle illusory learning.

Even though I decided to make the big challenge to learn to code, I still ran into procrastination issues. I procrastinated splitting my React code into multiple modules. I was dreading starting to learn unit tests.

For some reason, it is human nature to procrastinate and make problems seem bigger than they are. And the longer you avoid doing the thing, the bigger and bigger you make it out to be. Then when you finally start to learn it, you realize it wasn’t that bad.

One method for getting over this hump is to find a community or mentor and talk with others about what you’re struggling with. There are a bunch of great coding communities:

• Learn Programming Subreddit — redditors learning to code together
• CodeNewbie — a community that started as a weekly Twitter chat to connect people learning to code by Saron Yitbarek but has since grown
• #100Devs — free 30 week online bootcamp started by Leon Noel with an active community on Discord and Twitter

For more details, here is another post I wrote about learning a new technology using React as an example.

Coding is 99% failure. You spend hours and hours debugging and finally getting the error message to go away and then you encounter another error…

And then as soon as you get it to work then you’re done and you move on. And you start applying to jobs and are congratulated with more failure!

There isn’t much to say about this except that you need to learn to manage your relationship with failure. Coding is relentless problem solving. If you feel yourself getting frustrated or down, then shut your laptop, go for a walk, go to sleep. Likely when you come back, you can approach the problem with a clear mind.

Now get back out there and code!