Making Words Behave

A old poet friend of mine, who frequents the same café as I, explained the job of a poet was "to make words behave". And it struck me that this description described the role of a programmer exceptionally well. Poets and programmers both must wrangle words and make them behave. And if you look at source code, you'd be hard pressed to see anything more than words, spaces, and punctuation. Those are the same stuff of which poems are made. Is it little wonder then that our would be tasks so similar?

Code Poets

Now poets who write code may seem a bit pretentious, unless you view programs as particularly useful poems. What a poet seeks to convey in a poem is something meaningful to the poet. The efficacy of his work is measured by the emotional response invoked in his audience. And a poem's commercial value is directly linked to its impact culture, to the ears and eyes that incorporate its sentiments. And as a culturalware, poems have an incredible ability to shape identity, preserve history, and change mindsets. Look at the Greeks and their Iliad, the Anglo-Saxons and their Beowulf, the Judeo-Christians and their Book of Job and Psalm of Psalms. These can all be seen as cultureware, that program the identity and values of the group.

What makes programming such a peculiar poetry is the audience. A program must be written for both machine and human consumption. It need not merely convey understanding to other programmers, but also instruct the machine with exacting precision just how to operate. Like a poem, if a metaphor is stretched too thin or a motif repeated too often, the code may very well cease to function. As with poetry, code is formulaic language. And as with poetry, code often appears inaccessible to the general populace, too wrapped up in the conventions and jargon of a self-selecting elite.


Writing code is an exercise in designing metaphors. Programs are not so much about the numbers themselves, but rather what the numbers can be made to represent. Neo in the Matrix was confronted with the truth that "there is no spoon". The same can be said for the links on this page, the buttons in your web browser, and the scroll bar as well. All of these "things" are just an arrangement of colored lights, that change based upon how the software interprets a series of electrical signals coming from your mouse and keyboard. The only actual reality is a sequence of electrical pulses, which emit light to convey information. To the user, the illusion is the reality. To the programmer, the illusion is a metaphor.

Coming up with good metaphors is the first stumbling block all new programmers face. The translation of a recognizable metaphor into a sequence of 1s and 0s requires a kind of double-think. First you must see what the audience will see, then you must find a way to tell the computer to produce that illusion. Often when a user interface is clunky, or kludgey, or just plain wrong, it is because the programmer who designed it got trapped within his own metaphor, and could not see how it would appear to another human being. At times, holding both metaphors in your head can be much like trying to look at both sides of a coin at the same side.

The Basis for Translation

Writing good code involves translating between four basic modes of thought:

catch(e) " href="http://1.bp.blogspot.com/_XCDTVvEbBMU/Sh7pt2btflI/AAAAAAAAACM/ul3CUNxMV1U/s1600-h/opposition.png">

These four axis are all in opposition to each other, each striving to dominate the mental landscape of the program. Without finding a balance between the demands of each, the design of the software will be found lacking in some way. If the users' expectations dominate, the code may become bloated with too many features, become difficult to maintain as user requirements change, and run poorly or at great cost as the solution maps poorly on the machine's capabilities.

Similarly, if the development of the code itself takes precedence, it may not provide an adequate illusion to support the user experience. Support frameworks, 3rd party tools, and operating system may make the code easier to develop, but ultimately render it unmanageable by other programmers and too complex for the machine to efficiently execute.

Placing too much emphasis on the human aspect of the code, the component which makes it accessible to other programmers results in design decisions made not based on technical merit, efficacy, or ever user requirements. It is fad and fashion that drive the design. Using the latest hot programming language, or cool new framework, or just whatever they're teaching in school, may make the project manager's job easier, but does little to improve the quality of the code, the user experience, or the performance of the application.

Finally, letting the hardware dictate development and design results in a design skew which makes it impossible for both programmer and user alike to use and maintain the application. It is far better to change the hardware than it is to wedge a square peg in a round hole. Finding the right tool for the job includes finding the right hardware, as well as, software. And it is a practice far too common among programmers to view all CPUs to be created equal.