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
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.
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
xthat stores the value
1. To define a variable you have to use
varat 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
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.
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.