Why Courses Leave You Feeling Like You Know Nothing

You found a course. Maybe it was free, maybe you paid for it. You watched every video, you typed along, you did the exercises. Find the prime numbers in a loop. Pull a name out of an array. Reverse a string.

Then the last video ended, the certificate popped up, and you opened an empty folder to build something of your own. And nothing came. You stared at the screen and felt like you knew nothing at all.

I have been exactly there. When I started, I had one problem that never went away: where do I even learn this, and in what order? There is so much material online and almost nobody is direct with you. They teach you things you will never use, and nothing connects to anything else. You finish a course and you feel the same as before you started.

So first, the most important thing I want you to hear. It was not you. You are not too slow, and you are not missing some talent that other people have.

Think about what a typical exercise teaches you. How to loop over a list. How to read one item out of an array. These are real skills, and you do need them. But they are taught as little islands. Nobody takes you by the hand and says: this exact thing is what draws the product list on a web shop.

A real website is not a pile of separate tricks. It is a handful of simple ideas, connected, repeated hundreds of times. The loop you practiced is the same loop that puts ten blog posts on a page. The array of names is the same kind of data that holds your users, your products, your comments.

When a course teaches the idea without the connection, you do the exercise, you pass the quiz, and you walk away without the one thing you actually needed: the picture of how the pieces fit together. That is why you feel like you know nothing. You know the pieces. Nobody gave you the map.

• The exercises are toy problems, so you never see where the skill is used.
• Each lesson stands alone, so nothing builds into one whole.
• Watching feels like progress, but only building makes it stick.

Here is the classic exercise. You have a list of names and you print them one by one.

const names = ["Emily", "James", "Olivia"];

for (const name of names) {
  console.log(name);
}

Read it slowly. The first line creates a list with three names. The word for is the loop. It says: take the list, and for each item in it, run the code between the curly braces. Each time around, name holds the next item. First Emily, then James, then Olivia. Run it and you get three lines in the console. That is the whole exercise.

Now look at what a web shop does. It has a list of products, and it needs one card on the page for each product. Same shape, different data. Instead of printing a name, we build a little piece of HTML.

const products = [
  { name: "Wireless Mouse", price: 24.99, image: "mouse.jpg" },
  { name: "Mechanical Keyboard", price: 89, image: "keyboard.jpg" },
  { name: "USB-C Hub", price: 39.5, image: "hub.jpg" },
];

function renderCard(product) {
  return `<article class="card">
  <img src="${product.image}" alt="${product.name}">
  <h2>${product.name}</h2>
  <p>$${product.price.toFixed(2)}</p>
</article>`;
}

const html = products.map(renderCard).join("\n");
console.log(html);

Let me walk through every part, because this is the moment the exercise turns into real work.

• products is still a list, but each item is now an object with a name, a price and an image. This is what real data looks like. Your database returns something very close to this.
• renderCard takes one product and returns a string of HTML for one card. Notice it knows nothing about the list. One job: turn one product into one card.
• The backticks let us drop values into the text with the dollar sign and curly braces. product.name becomes Wireless Mouse. The extra dollar sign in front of the price is just a real dollar sign.
• toFixed(2) makes sure 89 prints as 89.00. Prices with one decimal look broken to a customer, so we always force two.
• products.map(renderCard) is the loop in a shorter form. It runs renderCard on every product and gives back a new list of cards. join puts them together into one block of HTML.

Run it and you get three finished cards, each one built from the same function, only the content is different. If tomorrow you have three hundred products, you do not write three hundred cards. You change nothing. That is the whole point of a loop, and now you have seen it do something real.

That is the aha I want you to have. The prime numbers, the arrays, the loops: they are not school problems. They are the engine under every list you have ever scrolled on a website.

If you are still building your first page and want the structure behind those cards, start with the beginner guide to HTML and CSS, and if you want to see how cards sit in a layout, the complete CSS Grid guide shows you how.

I like to write for everyone, so here is how that same example looks depending on where you are.

If you are just starting

A loop repeats something. A function packs one job into a name you can reuse. If you understood only that, you understood the most important part. Do not worry about the rest yet. Type the example, change the names and prices, and watch the output change. That is learning.

If you have built a few things

The better habit is separating the data from the way it looks. Data in one place, one small function that turns a single item into a card, and a loop that connects them. When a client says make the price red, you change one line, not three hundred. If your last project had the same markup pasted in many places, this is the fix.

If you have been around for a while

Here is the part courses almost never mention, and it is the part that gets people in trouble. We put product.name straight into HTML. For our own hardcoded list that is fine. The moment that text comes from a user, a form, a comment, or any outside source, it is dangerous.

Imagine someone types a name that is actually a piece of HTML with a script inside. If you drop it straight into the page, the browser runs it. That is called cross-site scripting, and it is one of the oldest ways to attack a site. The fix is to escape the text first, so the browser shows it as plain text instead of running it.

function escapeHtml(text) {
  return String(text)
    .replaceAll("&", "&")
    .replaceAll("<", "&lt;")
    .replaceAll(">", "&gt;")
    .replaceAll('"', "&quot;")
    .replaceAll("'", "&#39;");
}

const evil = '<img src=x onerror="alert(1)">';
console.log(escapeHtml(evil));

Run this and the output is <img src=x onerror="alert(1)">. The dangerous characters turned into harmless text. The browser prints the weird name on the page instead of executing it. Each replaceAll swaps one special character for its safe version. The ampersand goes first, because otherwise we would escape the ampersands we just created.

I believe you learn on a real project, starting easy and getting harder. Not exercises in isolation. Pick something real and small. A web shop page that lists products. An app that keeps track of your own inventory. A cash register for a small shop. You learn the loop because the shop needs a list. You learn functions because you are tired of copying the card. You learn escaping because you realize someone could type anything.

Every concept arrives the moment you need it, attached to a reason. That is why it sticks, and why the pieces finally connect into one picture instead of staying as separate facts.

One more thing I did the hard way. I used to start projects with no plan and no sketch. I built from my head until it looked good to me, and I never thought about semantic HTML, about search engines, about security, about what happens when real users show up. It works right up until it does not. Now I start with a plan, a rough visual, and a few questions: who uses this, what can go wrong, what is my Plan B? If you want the longer version of that thinking, read what separates hobby apps from real ones.

You have probably heard that you must study two or three hours every day, no exceptions. I disagree, especially when you are starting. People are not machines. Some days your head is somewhere else, you are sick, you are tired, and code simply does not go in. Forcing it on those days teaches you one thing: to hate it.

So take a day or two off when you need it. But be careful with the other side of that. Do not let the break turn into a week, then a month. Without a rhythm you do not build a habit, and you forget what you learned. The goal is a routine you can keep for years, not a streak you break in two weeks.

And here is a number I like. Getting one percent better in a day feels like nothing. But stack 365 of those days and you are in a completely different place than someone who did nothing. Small steps are not a weakness. They are how everyone who is good got there.

I wanted to program since I was about twelve. My older cousin went to a technical school, and I looked up to him. I saw what he did, I liked it immediately, and I never changed my mind. Later I had to start my education all over again in a new country, because of the language. It was not a straight line. There were detours, there were days I felt behind, and there were many things I did not know.

What I learned is that not knowing yet is fine. Plenty of people who work at big companies do not know everything, and they ask other people for help all the time. Nobody has the whole map in their head. The people who get good are the ones who keep going when they cannot see the way out.

Find something you love enough that it does not feel like a chore. For me it is programming. Some mornings I get up early to work on it, and some evenings and weekends I sit down to build something nobody is paying me for, because I want to. That is not advice to overwork. It is the opposite: when you love it, it does not feel like work, and you find the energy without forcing it.

• Pick one tiny real thing to build this week: a page with a list of items, for example. Not a tutorial project, something you actually care about.
• Type the product card example above, then change it. Add a field, break it on purpose, fix it.
• Write down one question you cannot answer yet. Questions are your map.
• Come back here. Every article on this blog starts from a real problem and ends with the piece that finally clicks.

A last thing, and I mean it. You can do this, and you have to believe that. If I thought you were not capable of it, I would not spend my time on you. Just do not give up, and you will always have me on your side.