My approach to the actual mechanics of writing code is as follows:

  1. First, I set up whatever environment is necessary to build and run the code. 
    1. If I’m working in a command-line environment, I write two batch files. 
      1. One is called “make” and contains whatever calls are required to build the code into an executable.
      2. One is called “go” and contains whatever calls are necessary to run the application through its test suite.
    2. This insulates me from worrying about the details of the operating system beyond the initial bootstrapping level required to get the batch files written in the first place. I settled on this approach in grad school, where I’d often have projects going at the same time in Windows and a couple flavors of Unix. It allowed me to focus on the code at hand without getting bogged down in the details of “what is the build tool called on this platform” and so forth.
  2. I then write a simple “hello world” program, and make sure it builds and runs successfully.
  3. From that point forward, I basically do test-driven development. 
    1. I figure out what the next function point to add will be.
    2. I write a test that will pass when the function is implemented successfully.
    3. I write the function and make sure it passes the test.
    4. I pick another function to implement and start again.
      1. I don’t like to have more than one function point in progress at any given point in time. This is not always possible, but my preference is to pick something, get it to 100% completion, and then not worry about it anymore.
      2. I keep my full test suite in play and run it often, to make sure that new functions don’t break existing ones. 
      3. I don’t move forward past the current work item until the tests pass. I am OK if I have 100% success on tests. I am still OK if I have 1 test that fails. If I have more than one test failing, I am not happy, and my focus at that point is on figuring out what went wrong and fixing it.

I think of this process as “island hopping.” That is, I start on a small island of running code (“hello world”). I add a little bit of functionality to that, and get it running. That’s another island. Now I can hop onto that island and start building another one. As I move forward, I know that all the ground behind me is solid, and the only questionable piece is the one I’m working on now. My test suite gives me some level of assurance that my new functions haven’t broken my old ones, so I can make orderly progress toward a goal.