Barely a week goes by without someone writing to support to say they cannot keep it up. Almost everyone blames their own willpower, but when we analyse the learning logs, people drop off at three quite specific points.
Drop-off point 1: setting up the environment
The first wall stands in the way before you write any code at all. The path is not set, the versions do not match, the error message means nothing to you. None of the time spent here feels like learning, so it eats motivation and gives nothing back.
That is why 4peiron lessons run entirely in a code runner in the browser: it steps around this point at the start. Setting up an environment is covered on its own terms in the Linux and Docker courses, at the moment you actually need it.
Drop-off point 2: right after you finish copying the example
Type it out as written and it runs. Change it slightly and it breaks. This state is what we mean by "thinking you understood", and it makes the next lesson feel as though the difficulty suddenly jumped.
- Deliberately break part of the code you copied, and read the error
- Rename the variables into your own words
- Change one line of the output
Just inserting those three steps makes a noticeable difference to how many people finish the next lesson. It is the same reasoning behind 4peiron's quizzes asking why the other options are wrong rather than simply which one is right.
Drop-off point 3: you have not decided what you want to build
If the only goal of your learning is "to be able to program", the finish line recedes forever.
Decide on something finished first, however small. A household budget tracker is fine. So is rock-paper-scissors against the computer. Once you have a goal, you can start deciding what material to skip.
In summary
Not sticking with it is a design problem, not an ability problem. Write down where you got stuck, and if you stop in the same place three times, take it as a signal to change the approach itself.