You've got it backwards.
First you design the game. All aspects of the game.
Then you break the functions of the game into smaller and smaller sub-functions.
When you get the game into the smallest pieces you then design the code using pseudo-code.
Only then do you start programming in whatever language you choose.
I think you should get familiar with some sort of library/framework to make games (OpenGL, openFrameworks, DirectX, etc). Once you have a good idea of how it works (you should at least kinda know stuff about threads, mutexes, callbacks - you'll learn this stuff when you learn about the tool of your choice).
I think that you should do this before you break the game into smaller pieces so that you can take stuff like multithreading, thread safety and so on into account when you break the game down, at least that is what I would do. I hope you agree, WaltP ;)