I consider myself a reasonably capable programmer and have learned enough web development to start making projects independently. However, whenever I sit down with a new idea, I often freeze at the coding stage and have no idea where to begin. Documentation doesn't always help because I don't yet know exactly what to look for, so I usually return to old practice projects and reuse parts of them. I understand that repetition can be useful, but I worry that I'm only copying patterns instead of truly learning. I don't use AI to build projects for me and want to understand how to approach the "learn while building" process more effectively.
3 Answers
Reusing code from previous projects isn't automatically a problem. Repetition helps consolidate what you've already learned, while unfamiliar requirements force you to research new concepts, read documentation, and investigate existing examples. If you want more growth, gradually choose projects that introduce one or two broader challenges rather than attempting something huge all at once.
Start with very small projects and focus on understanding what each building block does and how the pieces connect. Experiment with individual HTML elements, CSS styles, and simple bits of functionality. Break things on purpose, then work out how to fix them. Looking at older projects for patterns is fine, but make sure you understand why the code works instead of copying it blindly.
That makes sense. I'll focus on smaller projects first and spend more time strengthening my foundations and understanding.
A useful approach is to build the dumbest version possible. For a to-do app, begin with an input and a button that prints the entered text. Once that works, add one small feature at a time. You can also try rebuilding an old practice project without looking at the original, then check your work afterward.
The blank feeling often comes from trying to solve the entire project and its syntax simultaneously. Before writing code, describe the idea in plain English as a sequence of small actions. For example: the user enters text, the application stores it, the stored items appear in a list, and the user can mark one as complete. Then tackle one bullet at a time and look up only the specific concept you need. Documentation becomes much easier to use when you're consulting it for a concrete problem instead of reading it without context.
That breaks down the problem in a way I hadn't considered. I'll try planning the steps in plain English before translating them into code.
I usually understand projects when I'm following documentation, but I get overwhelmed when I have to build something that wasn't directly covered. Breaking the idea into much smaller tasks should help me know what to research next.