We have a reasonable description of what programmers actually do, that makes sense. The two key words, desire' andinsight', are things that it is difficult to discuss sensibly in packer business language, which concentrates on manifest `objective' phenomena. While this is a very good idea when possible, it can hamper progress when applied as an absolute rule, which is how packers often apply rules.
It is worth making a philosophical point here. In order for any communication to take place, I must refer to something that is already there in your head. One way a thing can get into your head is as an image of something in the external world, and another is by being part of your own experience. If a part of your experience is unique to you (perhaps an association between pipe smoke and the taste of Christmas pudding, because of visits to your grandparents), we cannot speak of it without first defining terms. Even then, I cannot have the experience of the association, only an imagining of an association. But if the part of your experience is shared by all humans (perhaps our reaction to the sight of an albatross chick), we can speak of it `objectively', as if the reaction to the chick was out there with the chick itself to be weighed and measured.
It has been argued that it is necessary to restrict the language of the workplace to the `objective' because that is a limitation of the legal framework of the workplace. This is just silly. How do journalists, architects (of the civil variety) or even judges do it? This is the area where managers have to use their own insight to control risk exposure.
We suggest that the real issue here is that we are not very good at software yet. We probably never will be - our aspirations will always be able to rise. We are culturally constrained and further influenced by the mature objective metrics that our colleagues in the physical, rather than information disciplines, routinely use.
To get anywhere with programming we must be free to discuss and improve subjective phenomena, and leave the objective metrics to resultants such as bug reports.
First, desire. In the example above, Ada likely did not begin with a clear desire for greater light. Her environment became non-optimal, perhaps uncomfortable, and she had to seek for a clear description of exactly what she wanted. This clarifying of one's desire is usually a nested experience where incremental refinement is possible and proceeds in tandem with the design. We will have more to say about the User Requirements Document later-- for now let us remember that the clarification of desire always has the potential to turn into a journey of exploration together with the customer.
Next, insight. This is the moment of recognition when we see that the interaction of the problem and the desire can be fulfilled by a given use of the semantics. It's kind of like very abstract vector addition with a discontinuous solution space. Or to put it another way, it's like doing a jigsaw puzzle where you can change the shape of the pieces as well as their positions, It is supremely intellectually challenging.
There is a pattern here that relates computer programming to every other creative art. We have three phenomena, Problem, Semantics, and Desire (heavy capitals to indicate Platonic essences and like that). Problem and Semantics are of no great interest to the AI or Consciousness Studies people, but that Desire has something odd about it. These three phenomena are addressed or coupled to by three activities of the programmer. Looking consists of internalizing the features of the Problem. Seeing comprehends the meaning of the Desire. Telling exerts the Semantics. Looking and Telling are domain specific. The poet might observe commuters, while the ecologist samples populations. The poet writes structured words, while the ecologist introduces carefully selected species. All of us do the same kind of Seeing. Talk to any artist about the good bits of your job.
We need all those wonderful mapper faculties to handle this stuff.
Programming is a mapper's game.
Copyright (c) Alan G Carter and Colston Sanger 1997
Top comments (0)