Joe's
Digital Garden

Programmer's Stone

Reading the Programmer's Stone, whose approach so far is not unlike Zen and the Art of Motorcycle Maintenance. The work is abstract, but the problem it is attempting to describe an issue with which we've no concrete words.

Mappers and Packers

In the first chapter, Alan introduces two concepts: the Mapper and the Packer. These are representative of two approaches to both learning and working.

The Mapper is described as an autodidatic individual, given to daydreaming, who learns through creating large internal models or maps that exist as reflections. This rich inner self collects new information about the world and relates it to the model. This mapper quicking intuits where change must occur through this model. This mapper sees larger boundary crossing relationships and in their work can appear radical.

The Packer, conversely is a being of memory. Their mental workings is to collect a large collection of information stored much like a hash map. They look for correct procedures and previously worked out solutions. They excel then at creating and enforcing a systematic approach to development. Thus we see the rise of the Scrum master and the JIRA ticket. They excell in this realm of pre-digested problems in an assembly line fashion.

Thinking About Programming

The second chapter of the Programmer's Stone discusses the purposes behind Software Engineering and how realizing those purposes leads to an improvement in the quality of that Engineering.

Adam posits that Software Engineering is a subjective aesthetic process, a form of communication by the Engineer to future efforts. It is not possible for the Engineering process to ever achieve an objective state, e.g. the kind of rote work that an assembly line might promote due to this intrinsic quality.

Engineering, Adam, continues is an unbounded process. We consider the task of the programmer to entail only the writing of code. But the programmer is actively engaged in collecting requirements, system design, and testing.

The act of programming is the act of recognizing an environmental issue, analysis of that issue, and then automating the solution to that problem through the application of a computer. Without the analysis step, that is, rote work (data entry), is the division between programming and mere computer use. In this process there is a desire and and insight. The desire to resolve the issue and the insight in how to resolve the issue. The progammer is a black box that accepts input and delivers solutions. What happens inbetween is not mindless.

Programming is a literary exercise. Excellence in composition goes a long way.

Programming is a process of breaking a task down into an atomic level. Further division beyond that level merely reverts to the original state. Yet from the atomic level tasks can be derrived to achieve the larger goal.

Programming involves improving the solution until it reaches a natural plateau of which further solving is mere bike shedding.

Linked References