Keep reading and watching videos, but cut that time down in half and use the rest of the time for exploring codebases and writing code of your own. If you do a code reading exercise, make sure you have the code open in your editor, and that you're able to interact with it via a REPL, its tests, etc.
Then from there, I'd recommend starting with very small, tiny projects. Ideally your first one should be something so simple you can do it in an hour or two.
Gradually work your way up from those tiny projects to slightly bigger ones. So start with one that takes an hour or two, then move up to one that might take 5-10 hours, then one that might take 20 hours, then 40 hours, etc. It's OK to stop at the size where you're feeling you're getting the most learning benefit.
Each time you try a new project, make it realistic if you can, but don't worry too much if you'll actually use it. The value is in having a rich context to try out ideas, not in the actual utility of whatever you build.
For each project you work on this way, choose one piece of unfamiliar technology or a new tool to try out. Don't pick more than that, otherwise it'll be too distracting. After a while, you should also try building something new and not introducing any new tooling into the mix, so that you can focus on your problem solving skills and making the best use of what you already know.
Don't be afraid to abandon projects you start this way, but don't be afraid to be a little uncomfortable while you work too. If you feel like you're learning it's OK to struggle, if you're just beating your head against the wall, drop the project and try a new one. Everyone has a bad practice day once in a while, but three in a row is a sign of a problem.