Code, Compile, Test, Repeat

I came across this image on Facebook recently and it got me thinking. My first old guy “get off my lawn” thought was that when I started coding one was lucky if they had a chance to compile more than once a day. But of course timesharing and interactive coding and development came soon after and we started compiling all the time. Today’s developers can pretty much compile anytime they want even if some systems are put together and built less frequently.

Back in the day a simple typo could result in hundreds of errors and it it was a tedious and often difficult task to determine which errors were real and which ones would be fixed by correcting a typo. Today’s IDEs are a big help in this area and warn of all sorts of errors from uninitialized variables to “Possible mistaken empty statement[s].” Syntax errors are easier to spot and  generally development is a lot easier than it was in the punch card and paper tape era.

Students, and even more advanced developers, can still get into trouble by not letting the compiler (or interpreter) do what it does early and often though. What I see students do is to try and write the whole program at one sitting before trying things out. At this point it can become very difficult, especially for beginners, to determine where in the code a logic error may be found.

I encourage students to break a problem down into simple steps and test as they go along. I try to model this in my demonstrations with sample runs so that students can see partial results, find errors or missing steps, and then move on to making the program handle what ever is next.

For some students I think a problem is that their programs/problems are too small. By that I mean they can (or think they can) get their heads around it and complete it in a single step. They think if it as a simple paragraph writing assignment. In fact most are at least more akin to a 3 to 5 paragraph paper. That requires a bit more thought, a bit more organization, and even a bit more editing. A larger project such as a semester or year end project is more like a research paper. A longer paper is not (usually) written in one go. It usually starts with an outline that plans out the steps and organization of the paper. A larger program is much the same. Development works better if there is an outline – perhaps using calls to method stubs with descriptive names.

Once outlined a program can be filled in and the individual methods tested and refined (or at least debugged) before moving on to the next one. Students don’t always think that way though. It’s something we’ll talk about before they start their semester end projects in the near future though. I hope it sticks.