One reframe that changed this for me: finishing is the skill, not building.
Almost everyone at your stage has three half-projects. The half you never do is the last twenty percent, the error handling, the case where the file is empty, the thing that happens when the network is down, making it work on someone else's machine. That part is boring, it is where all the real learning is, and it is what actually separates people who can build things from people who have done courses.
So choose the smallest project you can stand, and take it all the way to done. Done means: someone else could run it, it does not crash on obvious bad input, and there is a note saying what it is.
One finished trivial project teaches more than three abandoned ambitious ones. That is not a motivational line, it is about which parts of the work you are exposed to.
And on the second to-do list teaching you nothing: correct, because you already knew how to build it. The project has to contain something you cannot currently do, otherwise it is typing practice. One unknown per project is about right. Two is fine. Five is how you get stuck for a week and go back to a course.
Pick the annoyance, keep it small, and finish it.