There are two styles of coding, top down and bottom up (see Top Down and Bottom Up Design http://en.wikipedia.org/wiki/Top-down).. These two terms are commonly used in programming. You need to know what they mean, only so you'll know what other people are talking about, not because it's going to affect the way you code. The design method we've been using so far is bottom level up. The characteristics of bottom up coding are
You have a problem to be coded up. You start with the smallest part of the problem that can be coded, and you write fully functional code for it. You do this initially without much of an idea about coding the rest of the problem. Your assumption is that everything can be coded and you'll handle it when you get there, or if it can't be coded up, then that part of the problem will be left unhandled or handled later. Then you tackle another part of the problem, almost certainly a piece of code that interacts with the code you've just written.
In the nim game, your first piece of code would be the announcement of the rules, your next piece of code would record the player's play, the next piece of code would check that the player make a legal play... This process continues till all the code is written. You will very likely modify some or all of your earlier code in light of things you learn on the way.
Top Down coding
You analyse the whole problem and break it into logical blocks. These will become functions, or functions calling other functions. You figure out the information that the blocks need to function; these will become parameters for functions. You figure out the information the blocks will generate; these become return values. How deep you go down the logical tree is up to you: the blocks could be large (a function which calls lots of other functions, which you don't describe) or small (a function with only a few lines of code).
You check that the blocks when working together, do handle problem to be solved, by coding up stubs. A stub is a function that has limited functionality, but looks like a real function to the calling code. The stub for announcing the nim rules would just be the line
You would write the requirements for the function as comments, so that later (possibly months later, when you've long forgotten what the function is supposed to do), you (or someone else) writes the real code. The stub for the player's turn might just be
to indicate that the player picked up 5 counters. The player would always pick up 5 counters, no matter what the state of the game. You'd write the real specifications in comments.
Once you have all the stubs written, you run them as your first attempt at the program to check that the logic is correct and look for obvious design flaws. Then you start coding by turning the stubs into real functions.
Whether you use top level down or bottom level up, is up to you. I program bottom up. It seemed the only way for me, since I started coding with small examples and built up from there. I didn't hear of top down and bottom up programming for my first 30yrs of coding. No matter which style of programming you're most comfortable with, you'll always be doing both aspects. The bottom up programmer has to understand the whole problem enough to break off logical blocks to code. The top down programmer has turn all the stubs into functions.
In big projects with multiple programmers, the first step will be a top down design, after which pieces will be handed off each programmer. The pieces may be quite large and the programmer will then use their own approach (bottom up, top down) to analyse their part of the problem and start coding.
The concept of top down and bottom up is not restricted to programming, although it may have different names in other fields. In large engineering projects (building, freeway, dam, bridge), someone must do a top down design, figuring out the time and costs, put in a bid, get an order from the customer, all before the first brick is moved. Only then will subcontractors be called to handle the individual parts of the project.
One thing that goes wrong with top down, is that stubs written to handle unusual situations are left as stubs. You hear stories of badly behaving code and after much work to reproduce the problem, the maintainer finds a one line stub. This doesn't happen with bottom up coding, as the coder usually handles all the cases at one time, writes the tests and after checking that it all works, submits the code.
While there are no logical problems in top down design, once the design is handed out for implementation, it turns out that the management of large numbers of programmers is famously complex and characterised by catastrophic disasters. The causes of these disasters and the futility of the methods used are well understood The Mythical Man Month (http://en.wikipedia.org/wiki/The_Mythical_Man-Month), but are apparently beyond the grasp of most managers (or at least not amenable to current management methods). Anyone who intends to program for others (or work in teams) should understand the lessons of this book. You may think the book is so trivially obvious that you'll wonder why I even suggest that you read it. If so, I'm very glad, but be aware that you won't be meeting many people like yourself. After one of these expensive and highly visible projects are canned, the well compensated management will look at each other and say in wonderment "we did all the right things and still it didn't work" (there are people who will believe this).