Tutorials train recognition, not production. When you follow along, someone else makes every decision. Building alone requires you to break a problem down and make choices, which is a separate skill. Build it with small projects, planning on paper first, and a rule to struggle before you look anything up.
What people tell me
I have finished several courses and followed dozens of tutorials. While watching, everything makes sense and I can type along. But when I open an empty editor to build my own idea, I freeze. I do not know where to start, what file to create, or how to structure it. It makes me feel like I have learned nothing at all.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Following a tutorial and building alone are different skills. Nobody told you that, and it is not your fault.
- The missing skill is decomposition: breaking an idea into small, buildable steps.
- Plan on paper before you open the editor.
- Rebuild tutorial projects from memory, then change them, before starting fully original ones.
- Struggling alone for a while is where the learning happens. It is not a sign you are failing.
Why it feels so different
This is the most common message I receive from people learning to code, so you are in very large company. It is usually called tutorial hell, but I think that name hides the real cause.
When you follow a tutorial, the instructor has already made every decision for you: what to build, in what order, which files to create, how to name things, how to handle errors. You are practising typing and recognising code. When you open an empty editor, you suddenly have to make all those decisions yourself, and nobody has trained you for that. It is not that you have learned nothing. You have learned the wrong half.
The missing skill: breaking things down
Building software is mostly the skill of turning a vague idea into small, concrete steps. For example, "a habit tracker" becomes:
- Show a list of habits, hard-coded for now.
- Add a form to create a new habit.
- Save habits so they survive a page refresh.
- Mark a habit as done for today.
- Show a streak count.
- Add login so each person sees their own habits.
Each step is small enough that you can finish it, and each one teaches you something. The freeze you feel happens because you are staring at the whole idea at once.
A method that works
Here is the routine I suggest to people stuck in this exact place:
- Plan on paper first. Before touching the editor, write the steps like the list above. Sketch the screens. Write down what data you need to store.
- Build the ugliest working version. No styling, no clever structure. Just make step one work.
- Struggle before searching. When stuck, spend fifteen to twenty minutes trying yourself. Read the error. Try something. Then look it up.
- Search for the specific thing, not the whole thing. "How to save data to local storage in JavaScript", not "how to build a habit tracker".
- Finish, then improve. Only once it works end to end should you clean up the structure or add features.
A ladder from tutorials to independence
| Stage | What you do | Why it helps |
|---|---|---|
| 1 | Rebuild a tutorial project from memory without watching | Tests what you actually retained |
| 2 | Rebuild it and add two features the tutorial did not cover | Forces your first real decisions |
| 3 | Build a similar project with a different theme | Same skills, new problem |
| 4 | Build a small original project you actually want | Full independence, still small |
| 5 | Build something someone else will use | Real requirements and feedback |
Most people jump from stage 0 straight to stage 4 and freeze. Climbing the ladder makes each step manageable.
Change how you use tutorials
Tutorials are not bad. Use them differently:
- Watch a section, then pause and try to write the next part before the instructor does.
- After finishing, close everything and rebuild it the next day.
- Use them to learn one specific concept, not to build a whole project.
Accept the discomfort
Sitting alone with a problem you do not know how to solve feels awful. It is also exactly where the learning happens. The feeling of being stuck is not a sign that you are bad at this. It is the feeling of your brain doing the work that tutorials were doing for you. Over time, the stuck periods get shorter, and that is how you will know you are improving.
An example of the first hour on a new project
Here is what the first hour should look like for, say, a simple expense tracker:
- Ten minutes on paper. Write: "Users add an expense with amount, category and date. They see a list and a monthly total." Sketch one screen.
- Five minutes on data. Write the fields you need to store. Nothing fancy.
- Forty-five minutes on step one only. Create the project, show a hard-coded list of three expenses on the page. That is the whole goal for the hour.
When the hour ends, you have something running and a clear next step. That is how every real project starts, including the ones experienced engineers build.
A self-check for whether you are escaping tutorial hell
Every couple of weeks, ask yourself:
- Did I finish something without following a guide step by step?
- When I got stuck, did I get unstuck within an hour using documentation or a targeted search?
- Could I explain every file in my latest project?
When the answers start turning into yes, you are no longer someone who only follows tutorials. You are someone who builds.
If you are still stuck
Read What to Do When You Are Stuck Learning to Code and How to Start Your Career as a Software Engineer. For project ideas you can build step by step, browse the FYP ideas library. If you want someone to help you break down your first project, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- What to Do When You Are Stuck Learning to CodeThere has never been more good material for learning to program and the failure rate has not improved, which tells you the bottleneck is not access to explanation. It is that watching someone else solve a problem feels exactly like learning and is not. Sixteen heuristics for the first year, mostly about what to do at the point where you are stuck.
- How to Start Your Career as a Software EngineerA practical route into the first software engineering job: pick one language and stop shopping, build things too big for a tutorial, learn the five fundamentals you cannot skip, get your code in front of a human, and apply earlier than you feel ready. Includes a twelve month shape to work to and an honest read on what the current entry level market has changed.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.