Yo, go ahead and learn the basics. Once you got these, look for simple problems and try to solve them with whatever programming language you choose. You'll learn a lot by doing that. Whenever you think of some fun thing to try out, follow your interest and do it. Follow that scheme until you don't need to waste hours to solve trivial problems anymore
By then, you'll either have lost motivation or can tackle getting involved into some OSS project or starting one by yourself
For reference, that's basically what I did:
Create some stupid simple applications using Visual Basic, realize that VB sucks.
Screw "programming" (if you can even call it like that).
Learn C with some stupid online tutorials (they really sucked and I had a hard time learning how stuff works in detail lateron, but I guess learning it the proper way right from the beginning won't work anyway).
Lose interest because you can't figure out what kind of programs to write with plain C (I didn't really grasp the concept of a "library" back then, so I really couldn't do any exciting things besides printf lol).
Find out about Allegro, a nice and simple graphics programming library (and even though A5 still is a nice lib, I wouldn't suggest using it nowadays), get back into programming again.
Start coding lots of stupid little games (Snake, Asteroids, Breakout, etc...). Have some fun changing the original game concept with small modifications (more or less creative).
Get a book on 3d graphics (I guess one doesn't really need it if you have a solid understanding of maths, specifically if you know what matrices are that should be good enough to teach anything else yourself from internet tutorials).
Start coding lots of stupid little proof-of-concept 3d apps (.obj loader, simple renderer) in D3D9, fail horribly at creating actual games because you fail at having animated models (and don't see a reason to continue without them).
Screw game programming, it's a lousy job anyway.
Go look for some OSS project to work on, just for the sake of it and bscly out of boredom. Get the idea to work on Wine, look for an easy thing to start.
Start implementing the d3dx library in Wine. Nothing's easier than working on something new in the project that wasn't implemented at all before.
Write lots of patches and have 2/3 of them rejected because the maintainer is a douche bag and wastes a week of your time just to tell you that "that function should be static" (I see his point in code quality and stuff, but some of his concerns where just ridiculous).
Participate in GSoC for Wine, write some awesome code, give merging it to mainline a try, stop bothering because (again) some patches get rejected like 4 times in a row.
Meanwhile, find out about Dolphin. Follow development, read through the changesets of each commit. Have no clue wtf is going on. Try to look at the source harder, fail anyway. Sucks to be you, I guess.
Finish school and get bored in the last few weeks before final exams => start working on a D3D11 backend for Dolphin in your free time, tell everyone about it and say how you'll end up screwing the idea anyway.
Learn how D3D11 works since you never actually used it and while you're at it, write your first shader.
Copy over the full D3D9 backend, replace D3D9 functions with D3D11 ones. Fix compile errors, clean up some obviously stupid code, fix one or two bugs. Cheer about screenshots showing a broken Wii logo showing up at all (too bad I can't find it right now
) after like 2 weeks of work. Cheer even more when you optimized stuff good enough to get to the menu screen in NSMBW and it actually shows stuff.
Over the time, get a clue of wtf all the stuff in the gfx core of Dolphin is actually doing and learn that you should have a clue wtf you're doing when you write code. Meh, that development is bscly documented in my commit history anyway.
I guess that list can't quite be used as a guideline
i must apologise.i use a lot of mobile devices along with computers so it is difficult to make perfect sentences.ranging from computers to iPod touch to symbian with Swype.
