I DO know how to put them together in a broad sense. I figure that instead of just writing as you go it's best to have the whole idea of the game and every aspect of it written down first. That way when you write the code you write each segment/part of it based on the aspects of the game you've broken down. A good example would be for an RPG using Windows API and C++(sorry if you use Mac or such but the concept applies to all):

Character Stats:
HP > container variable representing the current amount > short or int HPCUR.
HP2 > container variable representing the maximum amount > short or int HPMAX.
STATS > container for each of the character's stat that will hold information for display on a status screen > ex. short or int STRENGTH or DEFENSE, LEVEL, etc.
Enemy Stats:
Same as character.
Command Menu:
CURSOR > One variable which represents the current position of a cursor upon command selection, such as in Final Fantasy games > CURHOVERATTACK, etc. Another variable or a cut-off extension of the same one can represent the cursor's confirmation prompt or "point" to a target before completing the selection or command > CURCONFIRMATTACK, etc.
Timing:
Use several timer variables or loops to determine who or what can act first. If one goes first then activate a BOOL to hold the data regarding the waiting value until the target finishes their attack and then call or check to see if the BOOL is true then complete the attack, negate a blank data bank of all data and repeat. Simple. > PATTACK = FALSE, PWAIT = TRUE; if(PWAIT){attack >> rest of code here}

I can go on and on if you want me to, but that's pretty much the ideal there. Who agrees?

1) Definitely the wrong forum.

2) The specification might as well be the manual, if it's written transparently. What matters is the inputs (through controller and whatnot) and the results (on screen, speakers, rules) and the rest is implementation details.

3) If you can't make simple games, than you do not know how to put them together in the broadest sense.

In any case, if you don't like programming, you might consider a different role. For example, game design. Get some game kits like Unity and whatnot and good old fashioned pencil and paper to learn how to make games by making & playing them. It's a mountain of fun.