Navigate back to the homepage

Why self-doubt is killing your ability to code and what to do about it

Kyrell Dixon
March 12th, 2020 · 6 min read

Most people don’t think of writing code as an emotional process, but I would argue that it is.

It feels really good to think up a solution to a problem, write code that perfectly translates your thoughts into language syntax, and then see your code come to life. It feels even better when you experience that gloriously rewarding moment where your code works perfectly without a single error!

You feel like the God of Programming, The Slayer of Bugs, Ruler of Code Editors.

I’m exaggerating (a little), but you can probably relate to the feeling. When it happens to me I feel like a complete boss. It’s such a rewarding feeling to write code and understand how it works.

But most of the time, that’s not how it goes.

What ends up happening, is you write a few lines of code and run your program—only to see errors. At that moment, a little bit of doubt about how much you know begins to form. But errors happen, and maybe this time it was just a small typo, so you keep working at it.

You write some code to fix your error, and then another one pops up. The doubt begins to build. Maybe you don’t know what you’re doing.

You update your code again and fix this new error and run the code hoping everything works out. However, this time the errors are on a completely different line of code that was literally just working. So now you’re completely lost and decide to delete all the code you just wrote and start over.

The errors go away, but so did your momentum. Now you feel like you have no idea what’s even happening.

This will not happen every time you code, but each time it does is stressful. Sometimes you just have to cool off and go for a walk or just try it again the next day.

Sometimes though, you really just don’t get it so you decide to copy some code from StackOverflow or a Github repo, modify it a bit, and use it for your project. Now everything works and you finish the project, but deep down you know that you have no idea how the code actually works.

You self-doubt grows along with the seeds of Imposter Syndrome.

If you haven’t heard of Imposter Syndrome before, it is basically the fear that people will discover that you are not qualified enough. This is usually an irrational belief experienced by even the most qualified people. And when I say the most qualified, I mean it. Even Nobel Laureates suffer from Imposter Syndrome.

So what do you do? How do you reach the point where you understand coding enough to get through your projects without having to rely on other people’s code? The key is to take a deeper look into how you learn to code in the first place.

It’s not you, it’s your mental models

A huge part of learning software development is about creating mental models that accurately represent a programming concept.

If you are learning to write HTML markup, you’ll probably start by learning how to use tags. In the beginning, you will form some idea about what a tag represents. Each tag will have a certain identity that you will associate with it.

For example, if you see an h1, you might think of it as the main heading of the page or the title of an article. You would never think, “I should probably add an image to this tag” because that violates the rules of the mental model you developed for what an h1 represents.

As you learn more, you discover that you can add a class to a tag to style it with CSS. Your overall model for how tags work evolves since you now understand that tags also can take attributes.

As you gain more experience with development, you will piece together an increasing number of concepts until you can create full websites and programs. Your mentals models are reinforced as you write code that uses them over and over again. But what can also happen in your learning, especially when learning on your own, is the mental models develop incompletely.

So let’s use another example to make this more clear. Let’s say you’re writing JavaScript and you want to define a variable. In that case, you might write:

1var x = 1;

This seemingly simple line of code is packed full of concepts that are easy to overlook. If you’re a beginner you might have learned about this as:

There is a variable called x that stores the value 1. To define a variable you have to use var at the beginning of the line, and you have to end it with a semicolon.

Everything works out until you look at some code somewhere written like:

1const x = 1

Now for the more experienced, it might make perfect sense what’s going on here, but to some, this completely violates their mental model for how defining a variable works.

What used to be a simple line of code becomes tons of questions without any clear answers.

What happened to the semi-colon? I thought you have to use var, so what is this const thing? Can you even use var anymore?

This is just a simple example, but the mental models we have are constantly being challenged with all the new languages, syntax, and frameworks that we learn. With so much out there to learn, it can feel like every time you’re feeling confident, there is a line of code that makes you feel like you don’t know anything.

That feeling is what I want to challenge. I want to give you another way of looking at development to make it easier to learn how to code with confidence.

Trust, but verify

The TL;DR (that’s Too Long, Didn’t Read for the uninitiated) answer is that you should trust your mental models when they work, but leave space for updates.

If you don’t trust the mental models you have, you will be crippled by inaction. Inaction could take the form of endlessly learning on Youtube or watching unnecessary amounts of tutorials. That’s not good because it takes you away from solving the problem. Instead, you’re spending time re-learning the same concepts over and over again while only making minimal gains each time.

Working on projects is a great approach to learning, but when you come across a new concept that goes against what you previously thought, you should take some time to update your mental model.

Usually, you have the right overall idea on how things work, but your confusion comes from a small piece of your understanding that needs to change. You don’t have to throw away everything you thought you knew, you just want to hone in on the gaps in your model and fill them in.

So using the variable definition code as an example, instead of being overwhelmed by questions and doubting yourself, simply embrace each question and seek out the answers. To understand what happened to the semi-colon you could:

  • Look through language documentation and read specifically about how semicolons work.
  • Read a blog post or watch a few videos and see if you really do need to add a semicolon at the end of the line.
  • Look for examples of what happens when you leave the semicolon on vs taking it off.
  • Create some new examples based on your current understanding.
  • Make mini predictions about what you think the code should do, and then test it to see if you get the expected results.

As you go through this process you will see that your initial understanding is almost right. All you need to do is learn a little bit more to clear things up.

The process can be time consuming, but trying to learn absolutely everything at once before you apply your knowledge is the quickest way to get overwhelmed and not really know anything. The key is to find a balance between learning and applying what you learn.

If you’re patient and learn what you need to understand the immediate confusion, your mental models will improve. The knowledge gaps will get filled in and your code will be evidence.

Learning takes time, but you can speed up the process

With that being said, I understand that the learning process takes time—time that you may not have. Projects tend to come with deadlines and meeting them might require you to take some shortcuts. So what do you do to complete your projects while learning efficiently?

Ask for help.

I am personally working to create content that will help you get over these hurdles efficiently through writing and tutoring. It’s my mission to help make this stuff easier so you can spend more time focusing on solving problems. You can reach out to me on Twitter, email me or schedule a one-on-one session to discuss your problems.

If you don’t want to work with me directly, look to peers and forums built for you to ask. There are subreddits like r/learnjavascript and r/learnprogramming, #CodeNewbie on Twitter, and of course dev.to features tons of people all working to create value.

Final thoughts

I have times where I am completely confused about what is going on with my code and have to struggle through my doubts to reach a solution. But I also know that pushing through is a natural part of the problem-solving process. At the end of the day, I believe that I can always find the answer given enough time. And if I don’t have time, I ask for help too.

If you take anything away from this post, know that software development is one of those fields where you can almost always find an answer if you are patient enough to look. Trust yourself, believe that you can find the answers, and they will come.

And if all else fails, Google is your best friend. You just have to ask the right questions.

Join our email list and get notified about new content

Be the first to receive our latest content with the ability to opt-out at anytime. We promise to not spam your inbox or share your email with any third parties.

More articles from Kyrell Dixon

How to setup Next.js with Tailwind CSS and TypeScript

Learn how to quickly configure a Next.js app with TypeScript and Tailwind CSS

February 2nd, 2020 · 2 min read

5 ways to loop through an array with JavaScript

Here are 5 ways to iterate through array values with examples and a quick explanation of how each one works.

January 23rd, 2020 · 4 min read
© 2019–2020 Kyrell Dixon
Link to $https://twitter.com/kyrelldixonLink to $https://github.com/kyrelldixonLink to $https://instagram.com/kyrell.dixonLink to $https://www.linkedin.com/in/kyrell-dixon/