I Stopped Watching Coding Tutorials and Started Building Projects

Sophie Weber — Fri, 09 Oct 2026 10:50:06 +0000

I used to think I needed to finish more coding tutorials.

Before I could start building something on my own.

Whenever I wanted to learn a new programming concept, I looked for a tutorial and followed along. If the instructor explained JavaScript functions, I practiced functions. If they built a website, I followed the same steps and tried to get the same result.

Everything made sense while I was watching.

The problem appeared when I tried to start something from scratch. I wasn't always sure what to write first, how to structure the code, or how to fix an error without searching for the exact solution.

That made me question my learning process.

Maybe I didn't need another long course. Maybe I needed to build something small and figure out what I didn't know along the way.

The Difference Between Following Code and Writing It

A simple to-do list is a good example of how different these two experiences can be.

The basic idea sounds straightforward: display a list of tasks, let users add new ones, and allow them to remove completed items.

But building it independently raises several questions:

How should I store the tasks?
How do I get the user's input?
How can I update the page when a task is added?
What should happen if the input is empty?
How do I prevent the application from behaving unexpectedly?

A tutorial might answer all these questions for me. Building the application myself forces me to think about them.

I might understand what an array does when someone explains it, but using an array to store tasks, remove a particular item, and update the displayed list requires a different kind of practice.

Following a solution helps me understand an idea. Building my own solution helps me practice applying it.

That distinction changed how I approached programming.

I Started With Smaller Projects Instead of Big Ideas

It's tempting to begin with something ambitious, such as an online store, a social media platform, or a complete productivity application. However, these projects can introduce too many unfamiliar concepts at once.

I find it more useful to start with a problem that has a clear outcome.

For example, a basic expense tracker could include just five features:

Enter an expense description.
Enter an amount.
Add the expense to a list.
Calculate the total.
Reject invalid entries.

That's enough to practice JavaScript functions, arrays, objects, conditions, and user input.

I would leave databases, authentication, charts, and complicated styling until the main functionality works.

I also look for inspiration outside traditional programming tutorials. For example, ClothingRIC designed an Impulse Buying Tool for shoppers, which is an interesting example of how a digital tool can address an everyday problem.

An idea like that could inspire a beginner project: a simple application that asks users a few questions before making an unplanned purchase and helps them think through their decision. Building a basic version would involve collecting input, applying conditional logic, and displaying a result.

The point isn't to recreate an existing tool. It's to identify a real problem and explore how programming could help solve it.

A useful beginner project doesn't need to be original or complicated. It needs to give you something meaningful to build and improve.

What Building a Small Project Actually Teaches You

Consider this basic JavaScript function for adding an expense:

const expenses = [];

function addExpense(description, amount) {
if (!description.trim()) {
return "Please enter a description.";
}

if (!Number.isFinite(amount) || amount <= 0) {
return "Please enter a valid amount.";
}

expenses.push({ description, amount });

return expenses;
}

console.log(addExpense("Lunch", 12));
console.log(addExpense("Transport", 5));
console.log(expenses);

This isn't a complete expense tracker. It doesn't include a user interface or save data between sessions. However, it's a useful starting point for experimentation.

Try changing the inputs.

What happens if the description contains only spaces? What if the amount is negative? What if you pass "12" as a string instead of the number 12?

These questions reveal how the code behaves and where additional validation might be necessary.

You could then add a function to calculate the total:

function calculateTotal(expenses) {
return expenses.reduce(
(total, expense) => total + expense.amount,
0
);
}

console.log(calculateTotal(expenses));

Now you have another concept to explore: the reduce() method.

Instead of memorizing it in isolation, you can understand why it is useful in a real situation.

That's what makes project-based learning valuable. The goal isn't simply to make the code run. It's to understand why it works, test its limits, and improve it.

I Learned to Debug Before Searching for the Answer

Debugging is one of the most useful skills a beginner can develop.

When code doesn't work, immediately searching for a complete solution can feel like the fastest option. But doing this every time can leave you dependent on answers written for someone else's problem.

A more useful process is to investigate the error first.

Reproduce the problem. Try to make the error happen consistently.
Read the error message. Identify the relevant line and check what the message tells you.
Inspect the values. Use console.log() or a debugger to see what your variables contain.
Change one thing at a time. This makes it easier to understand which change affects the result.
Test the fix. Check the original problem and other inputs that could cause similar issues.

For example, if an expense total is incorrect, I would inspect the stored amounts before rewriting the entire function. Perhaps an amount was stored as a string, an invalid entry was accepted, or the calculation used the wrong property.

The important lesson is that an error provides information. It reveals a difference between what you expected and what your program actually did.

You don't need to solve every problem without help. You need to develop the habit of understanding the problem before accepting a solution.

How I Use Tutorials Without Getting Stuck in Tutorial Mode

I don't think tutorials are a waste of time. They are useful for learning unfamiliar concepts and seeing examples of good programming practices.

The difference is how I use them.

Instead of following an entire course before attempting a project, I break the project into small tasks and look up the concepts I need for each one.

When working on an expense tracker, for example, I might learn how filter() works when I need to remove an expense, or how local Storage works when I want to save data between browser sessions.

After studying an example, I close it and try to implement the feature myself.

If I get stuck, I return to the documentation or tutorial for a specific explanation. Then I test my understanding by changing the example or applying the concept somewhere else.

I use the same principle with AI coding tools. Instead of immediately requesting a complete solution, I ask for an explanation or a hint.

A useful question isn't just, "Can you fix this code?"

It's, "Why does this function return the wrong result, and how can I identify the problem?"

That question encourages understanding rather than blind copying.

A Seven-Day Coding Challenge You Can Actually Finish

If you're spending more time watching coding videos than writing code, try this simple challenge.

Day 1: Choose a small project and list three essential features.
Day 2: Build its basic structure.
Day 3: Implement the main feature.
Day 4: Add input validation and error handling.
Day 5: Test different inputs and fix bugs.
Day 6: Improve the code and add one useful feature.
Day 7: Write a README explaining the project and what you learned.

Choose a project that matches your current level. A calculator, notes app, expense tracker, or simple API-powered application is enough.

Don't measure success by how complicated the project looks. Measure it by whether you can explain the code, identify its limitations, and make changes without following a tutorial line by line.

If you finish early, try rebuilding one feature without looking at your original code. This gives you a practical way to check what you've understood.

Key Takeaway

Learning to code can become frustrating when you spend hours studying but struggle to apply what you've learned.

The answer isn't necessarily to stop studying. It's to give yourself more opportunities to practice.

Choose a small problem. Build a basic solution. Test it, break it, debug it, and improve it. Use tutorials and documentation when they help you move forward, but don't let them make every decision for you.

You will make mistakes, and some simple features will take longer than expected. That's part of learning to work through problems rather than just recognize familiar code.

You don't have to finish learning programming before you start building projects. Building projects is one of the ways you learn programming.

Start with something small enough to finish, and let your next question come from the code you're actually trying to write.