Generally speaking, programming languages are like spoken languages, in that as a learner you’re unlikely to be able to memorize and reproduce long passages without extensive practice, and should instead focus on learning to say what you mean, rather than practicing set dialogues.

During job interviews, a question I used to often be asked was “how do you learn something?” (Phrased assorted different ways.) My answer was always pretty similar: don’t go into the learning process with the thought “I want to know x language” (or whatever).

Instead, have a goal to pursue. Don’t start thinking “I want to learn Linux,” start thinking “I want to use this operating system to make a server that can securely share media with my family.” Don’t think “I want to know Python,” come into it thinking “I want to make a chatbot.” (I don’t do much real programming, so I’m sorry if that’s a bad example.) Try to make it ambitious, but achievable. Originality and good execution are not even remotely requirements in this context. You just need a “why.” No one else will ever see what you do unless you want them to.

At least in my experience and that of those I’ve trained, if you just have an abstract target, you’re eventually not going to know where to go next and will run out of motivation. With a specific aim, even if you don’t comprehend the whole (yet!) you’ll often have a good idea of what the next step is and, whenever you achieve it, you’ll feel much more satisfaction by having gained progress on something you wanted than you would by completing an exercise in a book. As such, whatever lesson or lessons you may have learned will likely be easier to recall the next time you need them.

Repetition is key here. And solving problems.

I started many years ago with a “for beginners” book, and didn’t fully understand a lot of it by the end.

So I started trying to build something, and searched for answers to the things I couldn’t figure out (and went back to the book numerous times). I don’t think I ever finished that project, but by persisting through it, and figuring out how to solve the problems that I ran into, I learned how to build something, and it stuck.

Hard to say without knowing more about the problem. I mean, what went wrong with the code you copied from the book. Could be a simple typo, and example code sometimes also has typos or is just wrong - surprisingly, authors sometimes confidently type in code exampoles without running them. Carefully comparing the code you entered with the code in the book might reveal the problem.