Today's Programmers

I know I'm doomed to sound like an old fogy (is that how you spell it? I don't really want to know.) when you read this.  I started programming (IBM big iron) in 1959.  We had very limited random access storage, about 200 Kbytes and a processor that blazed away at a 12 microsecond instruction cycle, most instructions taking 2 cycles.  The stress of making the most out of every byte, and every machine cycle was intense.  Artful programmers (usually the PhDs) would come up with ways of using unused bits within the instruction itself, to squirrel away additional information, rendering the code impossible to translate when a new and faster machine came along.

Input/output on the IBM 704 was unbuffered, meaning, among other things, that the program had to wait for say, the printer to start rolling, before you could actually feed it a line of output.  This dead time was used to set up the first lines of printed output, usually the report title lines, converting data from binary to BCD (this was before the days of EBCDIC), inserting the current date and time, that sort of thing.

The programs I was working on at that time, using the IBM 704 at the National Bureau of Standards (now NIST), were ground-breaking applications of the fairly new "minimum path through a network" Moore algorithm, to provide tools in designing the Interstate Highway System.  A typical analysis run for testing an alternative Interstate configuration for the Washington DC region would take six hours of dedicated computer time (no multi-tasking in those days).  We could do this only after midnight, most likely at 3 AM.

Having said all that, I come to my point.

Today's programmers see little need to worry their heads about time and space -- they have a virtually unlimited supply of each.  The notion that a function call could reach down maybe a dozen or more layers of code is of no consequence - it all happens so fast!
 
During one of my brief spells as a contractor to the US Government, I witnessed some of the worst and most inefficient coding practices I could ever dream of.  I saw one case at a major regulatory agency where the programmer had reproduced the code for a function fifty times, changing only a line or two in each copy (and renaming it of course) to get it to perform the required function, this whole mess driven by a CASE statement!

When your PC begins to drag its heels, you may be fairly sure the chickens are coming home to roost.  Overloaded stacks and queues, processes waiting for processes waiting for processes to complete their tasks, ... ad infinitum (almost), stacks of interrupts waiting to be serviced, need I go on?  A tired PC is an overloaded PC.  PCs are like any other kind of worker, overload them and maybe they will not complain, but they will fail to perform.