I recently started reading Fred Brooks, Jr.'s The Mythical Man Month, an influential collection of essays on software project management.
In the introductory essay he has a paragraph that starts with the following words: "Why is programming fun? What delights may its practitioner expect as his reward?" He then goes on to list five reasons, in prose that is poetic:
First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things... I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake.
Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."
Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.
Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. ...
Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.
Of course, we all know that in addition to these joys that make programming fun, there are realities that subtract from the overall enjoyment. Brook addresses these later in the essay by enumerating the woes of programming. The first one dates Brooks's essays, which were written in 1975:
First, one must perform perfectly. ... If one character, one pause of the incantation is not strictly in proper form, the magic doesn't work.
While the programming language syntax rules are strict and literal, today's tools make this a non-issue. If I make a typo writing my code, Visual Studio underlines it with a squiggly. And the cacophony of information on the Internet provides a bounty of code snippets, tutorials, FAQs, and guides that virtually anyone these days can become a magician.
The next two woes Brooks lists are still applicable to today's programmers and are spot on.
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. ...
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.
The final woe Brooks lists is still applicable today, even more so than it was in 1975:
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.
For me, this is not a woe, as it does not subtract any fun from programming for me. Perhaps it's because I grew up with computers and the rapid and unceasing technology churn. It's second nature for me and most people whose birth date coincided with or came after the birth of the personal computer in the late 70s. But I can see an adult in 1975 would feel overwhelmed by the incessant improvements in technology, each new one rendering the older generation obsolete.
Brooks ends the essay on an upbeat note:
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. For many, the joys far outweigh the woes, and for them the remainder of this book will attempt to lay some boardwalks across the tar.
I'll leave you with some background on Fred Brooks: