It's very easy to get overwhelmed I think, but the worst sort of overwhelmed. It's one thing to be busy, or have so much to do that you don't know where to start. With some projects, the challenge is to figure out what you have to do to help you figure out what and where to start. Gusto and bad project planning is the enemy.
Gusto is great at the start of a project, but tearing into a project that is just starting to take proper shape is a bad idea - I think most peoples projects start out as some sort of tech demo that evolves - if the evolution goes too quickly then it becomes unwieldy.
With one of my newer projects, it's an application and is intended to run from script files, and do a lot of tasks - so a fairly complex project. I could get stuck right in and have half the functionality before giving up on it. But what I'm doing is micro-tasking, taking one item that I need and can add without reliance on any other new functions, and I don't work on anything else until it's done. Working like this is not a case of limiting what you are doing in your code, it's more like treating the code as an entire solution to many problems. The one micro-task might be to add a GUI control for scrolling something (scrollbar if you like) - so would need adding to a script file to test it, and I would have to add the handling code of course, and maybe some art media.
It might take an hour to finish, but it'll be a complete and working component to the project, each micro-task like that adds to the functionality. The next task might be to add an image that can be scaled and scrolled, so the previous micro-task feeds the next. It's a bit like coding with a leash on, because you might think ''I'll add in the image and worry about scrolling later''. But, if I did that, I'd probably have a scroll and scale factor on the image - however if I add the scrollbar handling first - I'd set a start and end range, assign it to a GUI control, and have a much more elegant system, that will be used several times over.
I guess that's more like micro-planning - not really following a distinct route to completion, but taking on the massive puzzle, 1 piece at a time - nobody writes a guide on making a specific jigsaw puzzle, nobody expects a sculptor to know how many strikes of the chisel they will take. Coding is organic - forget the idea that it's a strongly technical thing - the coding process is far more organic than people might believe or admit. You guys still make stuff up as you go along right? - not detracting from planning things properly, but when I do that, usually it's more a case of laying it out in my head, through the paper, through writing it down.
Old Chinese proverb coming up (again), and this one I did not get on UK Gold

...
To HEAR is to FORGET.
To READ is to REMEMBER.
To SEE is to UNDERSTAND.
Sometimes it's good just to write things down, and never bother reading them - the thought processes for writing are hardwired into our learning mechanisms, so writing is usually beneficial, even if its never read. It triggers memories and gives the non-impetuous areas of your brain a chance to get a word in.
Anyhoo, hope someone knows where I'm coming from, would be terrible to think I'm the only fruit loaf on the forum.