Save Your Brain

Journeyman programmers burn their brains trying to do the work that is best done by the computer, and they never succeed with their real job, which is focusing on creative programming and programming logic, rather than wasting their time on programming detailsdetails that should be automatic. For writers, the instant spell-check and grammar-check available at the push of a button on a Mac or PC frees time for content rather than for mechanics. Programmers should utilize the compiler in exactly the same way.

You have at your fingertipsliterallythe biggest productivity multiplier since the harnessing of electricity.

In 1992, five years after chess Grandmaster Garry Kasparov lost a tournament to IBMs supercomputer Deep Blue, he lamented to The New York Times that what he had been up against was the brute force of calculation. And indeed he was. Happily, the brute force is with you, not against you. You can harness it. So let the computer show you how successful your latest code is, while you are taking a mental break and preparing for your next block of creative programming.

Never just list your source program on a printer and review the source code you have keyed as the source program. Reviewing your source code as you wrote it, without compiling it, is almost always a very big waste of time, because only the program compile is the final judge of whether your code is correct enough to create an object program. A successful program compile also allows your program logic to be tested with datatesting you should do with virtually every small block of programming.

In the early days of computing, we had serious limitations on the design and implementation of projects because our computing power was very slow (often allowing only one compile a day, or more precisely, at night, after the prime production computer shift).The source programs were keypunched into decks of punched cards rather than stored on disk, and we worked with computer printouts rather than with online display terminals. Just to change a single line of source code, we might have to spend five minutes to read the source program card deck into the computer with the card reader before the sometimes hour -long process would even start. Then it would take several minutes for the printer to print the results of the compile before we would know if our change had errors. Today, that entire process might be condensed into ten secondsthe time it takes to determine and act on the results of a program compile.

Sometimes we would write a program that would randomly access tens of thousands of disk records. Wed get really alarmed when the disk drive rocked back and forth slightly as the disk arm raced back and forth across the 10-inch or 14-inch disk platters. Today, the disk drives are buried inside some computer cabinet, the disk platters are one or two inches long, and the read and write mechanisms float over the disks so quietly that programmers are unaware of how many million disk-record accesses are taking place. And, for the most part, programmers dont need to care about it.

It is almost comical, at least to me, to observe programmer techies working so hard and long to save nanoseconds in a program rather than focusing on the business process of the project. They justify their work as being efficientand yet they run the entire program only once a week, though it executes in one computer (CPU) second.