What you're talking about is more software engineering than programming. It's a little bit architecture, a little bit "best practices" and "design patterns," a little bit working with others. While there are books that can help, most of it comes from experience. Nobody starts out writing, say, Microsoft Word.

Think about a large, "real" program that you would like to write. Now think about the various pieces you need to build to make it work the way you want. For example, in a modern first-person game you will need a 3D graphics engine, non-player-character AI, a music/sound module, a physics engine, and a top-level module that enforces the rules of the game (knows the "map", how the various characters interact, etc.). And then there is the artwork and character design and the music, none of which are code but which are necessary for the game to be complete.

Now: Which of these will you build yourself and which will you get elsewhere? Most large software projects are not programmed from scratch. Perhaps you will use an off-the-shelf 3D engine and music/sound module and program only the things that make your game unique. OK, so you have to figure out what third-party modules you're going to use, which will involve factors like cost, what languages they work with, what features they have, how their API is designed (i.e., how complete it is, how well it fits with your personal programming style, etc.). Maybe you will write "proofs of concept" or test programs using one or two candidates for the various third-party modules to make sure they will do all the things you need and are easy for you to use.

Also, even the code you want to write yourself may be too big a job for you alone to complete in the time frame you have in mind. How many other programmers do you need working on the project? How will you split up the job? How will the various modules be designed so they all fit together even though they were written by different people? How will you all work on the same source code without wiping out each others' changes (answer: version control, which is extremely useful when you are working solo but indispensable when working with others).

Once you have figured out what modules you want to write in-house, you perform the same process. Figure out the pieces of each module, how they should fit together, and which you will write yourself and which you will get elsewhere. Continue breaking things down until each piece is small enough for you to hold in your mind, for you to say, "yeah, I could write that!" And then do so. As you do, you will encounter unforeseen obstacles in how the various pieces of your program fit together. These will be frustrating, but they are opportunities for you to learn more about your craft, and should be viewed that way.

Initially, you will only be able to hold very small pieces of your program -- say, individual functions -- in your mind, and so you will have to break things down a lot before you start coding. As you gain experience, you will think in functions rather than needing to think about functions and start thinking about objects. And then you'll be thinking in objects and thinking about larger modules. Finally, you will be thinking in modules and thinking about whole, large, real programs.

And then you will discover that you still have a lot to learn... but so it goes. If, as a programmer, you ever stop learning, you are obsolete and will be replaced with a newer model.

Anyway, don't be afraid, and don't worry if this sounds... awful or impossible and you don't really want to be a programmer after all. It's not for everyone. I love music and desserts, and I can play keys a little and cook some dishes, but I am not willing to put in the time it takes to become a great musician or a master chef.

If it turns out you don't want to be a programmer writing large, real, desktop apps, there are other types of programming jobs. You could become an embedded programmer, for example. There are definite, interesting challenges involved in writing embedded programs, and you are doing useful work, but typically the programs are rather smaller than desktop apps. Or you could write Web apps. On the Web, it's easy to glue little bits of functionality together, so you could write (e.g.) a Web comment system and it would be useful even if it's not a whole Web application. It is easy to incrementally improve stuff on the Web, too, so you can start with (say) a basic Web mail client and, over time, evolve it into something like GMail. (But don't do that, because then you'll be competing with GMail.)

If you don't want to be a programmer at all, but still want to work with computers, possibly you could go into IT or some other technical field. In these cases, knowing as much programming as you already do is very useful, because your peers may not even have that much. Or, you know, become a musician if that appeals, because (like most fields) it involves computers today. Write little programs that manipulate audio or MIDI files in various clever ways, thus making you a better musician. You will find that whatever programming skills you have can be applied in a lot of fields to make you better at your job.