Cartoon - Why Compile Time == Play Time?
Written by Mike James   
Tuesday, 27 March 2012

This week's selected xkcd cartoon has raised an unexpected issue. Why exactly is it that programmers were, and are, allowed to treat compile an other non-productive times as play time? Why aren't they expected to get on with something useful?

Writing code is tough.

If you don't agree with that sentiment then you just aren't a programmer.

Writing good code is even tougher.

There are lots of times when some automatic procedure brings the writing of code to a halt. Back in the early days we had batch processing where a programmer had to wait for hours to see the results of a change.

Later the need to compile large programs using relatively small machines introduced similar delays. Today things can be arranged to be more productive with better build systems and clever things such as continuous deployment, but in most cases there are still chunks of time in which the programmer has simply to wait until they can push on with the next task.

So why not get them to do something more productive than simply waiting?

This is one of the things that makes programming slightly different from other tasks.

A programmer has to understand at least the section of the program that they are working on, and this is a difficult thing to do. For a program of a realistic size it simply doesn't all fit inside the head. Over time we have developed ways of compressing the complexity of a program - by organizing it as functions and modules and later by using objects. Even so there is a limit.

Psychologists say that the human information processing system is limited to doing about seven things at the same time (this is a very rough summary of a full information theory model of human cognition).

If a programmer was to go off and work on another program while the first was being processed then the time to load up the new information before starting work would probably be longer than the compile time. In addition, the confusion caused by the dying memory trace would probably add to the chances of introducing a serious bug. Put simply:

  • working on one program is hard
  • working on two programs is much much harder

So the general rule is:

one program to one programmer


This rule can be broken if the program is small enough, trivial enough or similar enough to another. If you are in the lucky position of being a student of computer science, for example, then the evil lecturers will have no worries about giving you multiple programs for homework - but these aren't real programs.

In the real world, what is to be done with the dead time?

Back in the days of punched cards and batch processing, conscientious programmers would read through their code and start marking it up with changes  that might be implemented at the next run if everything went well with the current run.

Even today concentrating on the program in hand is the best way of getting something useful out of otherwise unproductive time - unless that is, you prefer the sword fight approach...



More cartoon fun at xkcd a webcomic of romance,sarcasm, math, and language

Related Articles

Magic Number Seven

More monitors!


raspberry pi books



or email your comment to:


To be informed about new articles on I Programmer, subscribe to the RSS feed, follow us on Google+, Twitter, Linkedin or Facebook or sign up for our weekly newsletter.



Last Updated ( Thursday, 29 March 2012 )