If you want to be future proof, the best advice I can give you is not enclosing yourself into a technology.
So don't learn APIs blindly. Learn how they are conceived. What are the philosophies behind the scene? What are their advantages and flaws? Think software in general, not a specific technology.
You can also work on good program conception, going to OOP and AOP is a good choice IMO. But don't just understand the mechanism, truly work on the philosophy behind the mechanism.
Don't neglect general computer science, like data structures and algorithms, because they are cross technology knowledge which is always useful.
Also go for good practices. You often have dozen ways to do something, but most of them are crap : bug prone, hard to maintain, hard to understand later or by another programmer, etc . . . Usually, the code is harder to read than to write. So learn how to spend a little more effort on writing to make the reading easier (because you'll read code more than you write).
Learn effective techniques to debug (smart use of log and debugger) and test (how to write code that can be unit tested easily and how to automate these tests).
Then, you'll need a general technology background. I'm talking about very broad knowledge, like how does a processor work (cache miss or branch prediction are good start), about UNIX systems, about network protocols like IP, TCP and Ethernet, etc . . .
In the end, learn how to learn. If you know how to learn, then you can adapt.
You'll need some strong knowledge in specific technologies to be able to find a job, but those are outdated really quickly (think about COBOL for example, or web programming at the time of the IE/Netscape war). So don't rely on them to be future-proof. They will be key to get hired, but definitively not what makes a great programmer and what will make your skills durable over time.
EDIT: If you are just starting, you should definitively get something done. Anything, really. A game like Tetris or snake is a good start, and fun. If you don't get things done, you'll spend to much time learning and really don't get the experience needed to fully understand what you learn.
Let's set an example with design patterns. Design patterns are great and you should definitively use them. But if overused they'll make your code complicated and hard to understand. You'll have to face the problem that a design pattern solves and lose some time trying to solve it or its side effects to fully understand what the design pattern is about. Design patterns must be used as small refactorings over time when code grows. And you'll know when a design pattern is needed when the benefit of it is bigger than the code complexity induced by its use. This requires experience.
So definitively, get things done, them learn from your mistakes. I can't insist more : GET THINGS DONE !