Overcoming 7 main problems of learning to code for people who don't have a developer job

Zell Liew 🤗 - Apr 21 '21 - - Dev Community

If you don't have a job as a developer, learning how to code becomes a much bigger challenge for a simple reason — developers can learn to code on the job.

I want to share with you 7 major challenges people face when learning, especially if they don't have a developer job. I'm also going to talk about how you can overcome each challenge.

The 7 major challenges are:

  • You don't have the energy to code
  • You don't know what you should be learning
  • You want to learn fast
  • You panic when things go wrong
  • You don't have anyone to mentor you
  • You get distracted easily
  • You forget what you are learning

Problem #1: You don't have energy to learn to code

Work can be draining. When you get off work, your brain is fried. All you want to do is lie on the couch and rest. If that happens to you, it can be really difficult to sit down and learn something.

Family can be draining too. If your family members demand your presence, you can't dedicate that time and energy to learning something. You have to spend your energy on them. For example, try learning when you have a 2-year old kid in the house. It's gets especially challenging.

There are three ways to overcome the problem of not having enough energy.

Reduce energy drain

If you're working on a job that demands a lot of concentration from you, you're going to be drained after work. It's going to be really hard for you to learn anything after work.

One possible way to overcome this challenge is simply to change to a job that's less demanding. You may get lesser pay from it, but if dedicating time to code makes you happier (and can potentially bring you more money in the long run), then it makes the short-term switch worth it.

Reducing energy drain on the family side can be challenging. If you have a kid, there's nothing much you can do. You have to spend time and energy with the kid.

But when the kid sleeps, you can arrange with your partner (or parents, or anyone who lives together with you) to give you some time to learn. Ask them not to disturb you so you can concentrate on learning, so you can focus on bringing them a better future.

Optimizing energy usage

One of the best things you can do is to learn something after you wake up. That's because you're most well-rested, which means you have more energy, willpower, and willingness to sit down and learn something new.

If you spend 30 minutes in the morning with a well-rested state, you're going to have better results compared to spending the same 30 minutes after work in a tired state.

You want to find ways to structure your day so it complements your learning time rather than working against it.

Increasing energy capacity

This one is easy to say but hard to do.

To increase your energy capacity, you need to stretch yourself. This means you'll have to learn even when you're exhausted. Your learning experience initially may be lousy, but continue to keep at it and you'll eventually get more energy to learn.

This concept is similar to building up your muscles to run a marathon. The first time you run you'll run out of breath relatively quickly. You get tired and you don't feel like running anymore. But as you practice you get better. You have to practice consistently or your energy capacity will drop again.

One bonus tip for improving energy capacity is to do physical exercise like running. It works because the physical body allows us to carry more energy when we're healthy. So it helps to eat well and exercise well.

Problem #2: You don't know what you should be learning

How do you decide what to learn? Most people have this question. When you have such a question the first thing you do is probably Google.

And you may have ended up with a huge developer roadmap like this.

huge developer roadmap

What's the first thing you notice when you see such a roadmap?

If your reaction is "oh my fucking god", you're not alone. Most people will look at this roadmap and have the same reaction: oh my fucking god! Then _they get overwhelmed by the amount of things they need to do. _

Following large roadmaps like this one is a surefire way to kill your joy for learning.

For example, most people who start out learning to code don't really know what DNS or HTTP is. They don't really care. They just want to make a website. If you ask them to research what HTTP is, they're going to go "what?". Why do I have to learn that? Simply put, they're not ready to take on this information yet.

If you force yourself to take on information you're not ready or willing to learn yet, you're going to be frustrated. You're going to think you're not a developer material, and you're going to give up.

Don't do this to yourself!

There's a much easier and more fun way to learn.

The easier, better, more fun way to learn

You have to start by throwing away the concept of a roadmap and focus on the things you want to learn. This allows you to set smaller challenges that you can complete, which gives you the confidence to take on larger challenges.

For example, when I started out learning web development, I only knew I wanted to be able to code out a design and put it on a website. The first step, is hence, code out the design.

So that led me to search for videos showing me how to turn a design into a website. Specifically, how to turn PSD into HTML and CSS.

I followed those tutorials and coded along. At the end of a few tutorials, I set myself a challenge to replicate Tutsplus website which looked like this way back in 2012.

When I completed that challenge, my next step was to figure out how to put the website online. At that time Wordpress was the rage, so I picked up Wordpress. Once I was able to code up something with Wordpress, the next steps were to buy a domain name, choose a web hosting company, and publish the website.

It was simple like that — I didn't even think about Git back when I started. I only picked up Git much much later, after learning even more CSS.

Notice I also didn't jump into JavaScript? That's because I wasn't interested yet. When I got interested, I started learning more about it.

Don't worry about becoming great

We all want to become amazing developers. If you’re an amazing developer you can have lots of job opportunities and connections. Your work career is going to be easy. You don’t have to struggle so much.

But the unfortunate fact is we don’t start out amazing* We start out ordinary.

If you’re ordinary and you dream about the amazing things, you’re setting yourself up for frustration — because you don’t have the skills to back up what you wish to do.

It's far better to create ordinary things when you're starting out.

Maybe you become amazing and you won't even know it after a while.

Problem #3: You want to learn fast

Learning fast is a trap. Unless you already have a track record of learning things fast, you're most probably going to fail.

When you try to learn fast, you try to "complete" a course or articles in the quickest time possible. When you do this, you're likely to skip concepts that are hard to digest. If you don't understand these concepts, can you truly say you've learned anything?

While speed is important, the amount of information that actually gets into your head is also important. We need understand what's going on.

So I highly recommend learning well instead of learning fast. You're going to get way more progress and speed this way.

Problem #4: You panic when things go wrong

Things rarely go right all the time. They're likely to go wrong instead. If you wish to be right all the time, you're going to have a very hard time learning to code.

Don't panic. You need to get really good at figuring out what went wrong. This a skill we call debugging in the coding world.

It's actually super easy to master debugging — you already have errors that tell you precisely what went wrong. So use those errors to help you figure it out. I talk more about debugging JavaScript here. It might just help you out.

Problem #5: You don't have anyone to mentor you

This is the worst possible problem if you don't have a developer job — you really have no one to mentor you and guide you through the learning process.

  • You don't know what the hell you did right
  • You don't know what the hell you did wrong
  • You don't know whether your code is good

This lack of mentorship can paralyze many people because they want to become great developers. (See above point about great developers again).

One common attribute of great developers is the ability to write clean, maintainable code. But is that really the only definition of great developers?

I once had a friend who complained to me about an excellent game developer. He told me the game developer builds excellent games, but he uses iterative code instead of declarative code.

If you're into the programming world, you would know of the debate between declarative vs imperative programming. Declarative programming is preferred since it's more understandable.

Even though the game developer used imperative code, can you say he's a bad developer? No, you can't. He's already producing games that work!

Producing stuff with bad quality code makes you a better developer than producing nothing with good quality code.

If you want to become better at the craft, you can always reinvent the wheel or learn from various experts.

Problem #6: You get distracted easily

There are many reasons why you can get distracted. But distractions usually fall into two categories:

  1. You're really tired and you need some rest
  2. You're afraid of something and you're running away.

If you're tired, feel free to take a rest! Don't feel bad about needing to rest. Even marathon runners need to take a break when they're not running.

If you're afraid of something and you're running away, you need to sit down and face the whatever is trying to make you run away. Even if the problem gets too hard, sometimes you just have to sit down and figure it out.

Problem #7: You forget what you learn

Human beings have two kinds of memories — short-term memories and long-term memories.

When we learn something, we store what we learn in the short-term memory bank. They only get transferred into the long-term memory bank if we keep using it for a long time. If we don't use the information, we simply discard the information.

So it's a given that we will forget something.

There are three ways to overcome this problem.

Train your memory

You can learn techniques to improve your memory power. This lets you remember things for longer. Moonwalking with Einstein is a great book that introduces various systems that memory experts use.

Just be aware that memory is a skill. Dedicating time and energy to training your memory doesn't automatically make it easier for you to remember code. You still have to work at it.

Write notes

Since we forget anyway, why not make notes about everything we learn? If you forget something, you can always look back at your notes.

Don't worry about referring to your notes. Life is not an exam. You won't lose marks for referring to your notes.

It's always better to make your own notes (instead of using other people's notes) because you remember things from your notes much faster.

Practice

Since usage of knowledge stored inside short-term memory converts it into long-term memory, the only other way to combat memory loss is to practice what you learned.

Don't make practice harder than you think it is. All you have to do is make stuff whenever you can.

You also don't have to practice things like code katas since you don't write that kind of code when you make things.

Practice what you need. Nothing more.


Thanks for reading. This article was originally posted on my blog. Sign up for my newsletter if you want more articles to help you become a better frontend developer.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .