Not all is delight, however, and knowing the inherent woes makes it easier to bear them when they appear.

First, one must perform perfectly.  The computer resembles the magic of legend in this respect, too.  If one character, one pause, of the incantation is not strictly in proper form, the magic doesn't work.  Human beings are not accustomed to being perfect, and few areas of human activity demand it.  Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.

Next, other people set one's objectives, provide one's resources, and furnish one's information.  One rarely controls the circumstances of his work, or even its goal.  In management terms, one's authority is not sufficient for his responsibility.  It seems that in all fields, however, the jobs where things get done never have formal authority commensurate with responsibility.  In practice, actual (as opposed to formal) authority is acquired from the very momentum of accomplishment.

The dependence upon others has a particular case that is especially painful for the system programmer.  He depends upon other people's programs.  These are often maldesigned, poorly implemented, incompletely delivered (no source code or test cases), and poorly documented.  So he must spend hours studying and fixing things that in an ideal world would be complete, available, and usable.

The next woe is that designing grand concepts is fun; finding nitty little bugs is just work.  With any creative activity come dreary hours of tedious, painstaking labor, and programming is no exception.

Next, one finds that debugging has a linear convergence, or worse, where one somehow expects a quadratic sort of approach to the end.  So testing drags on and on, the last difficult bugs taking more time to find than the first.

The last woe, and sometimes the last straw, is that the product over which one has labored so long appears to be obsolete upon (or before) completion.  Already colleagues and competitors are in hot pursuit of new and better ideas.  Already the displacement of one's thought-child is not only conceived, but scheduled.

This always seems worse than it really is.  The new and better product is generally not available when one completes his own; it is only talked about.  It, too, will require months of development.  The real tiger is never a match for the paper one, unless actual use is wanted.  Then the virtues of reality have a satisfaction all their own.

Of course the technological base on which one builds is always advancing.  As soon as one freezes a design, it becomes obsolete in terms of its concepts.  But implementation of real products demands phasing and quantizing.  The obsolescence of an implementation must be measured against other existing implementations, not against unrealized concepts.  The challenge and the mission are to find real solutions to real problems on actual schedules with available resources.

This then is programming, both a tar pit in which many efforts have floundered and a creative activity with joys and woes all its own.