The trap of the endless tutorial
Watching someone else build a to-do app is comfortable. It feels like progress because you understand every line as it goes past. Three weeks later you sit down with a blank file and cannot start.
Understanding someone else's code and producing your own are different skills. Only one of them is the thing you are trying to learn.
What worked
Short, daily, and typed by hand. Thirty minutes a day beats a four-hour Sunday session, because remembering matters less than returning. Type the examples out rather than copying them — your hands learn syntax that your eyes skim over.
One tiny program per session, finished. A tip calculator. A name formatter. A script that renames your files. Finished and slightly boring beats ambitious and abandoned.
Say the goal out loud before you write code. "Print each item and its price" is a plan. "Do something with the list" is a hope.
Get stuck in public. Ask the question in a community, in writing, with the error message included. Half the time the answer arrives while you are typing the question.
Keep a log. One line a day: what you built, what broke, what you now understand. It is the only reliable evidence that a year of effort went somewhere.
The part nobody says
Being stuck is not a sign you are bad at this. Being stuck is the job. Every working programmer spends their day not knowing why something is broken and finding out — the difference is only that they have more practice being comfortable there.
Start with something small today. Then come back tomorrow.