I was re-reading The Archaeology of Knowledge (1969) by Michel Foucault and came across a fantastic passage at the end of the introduction. The passage is in fact an exchange between two voices, although the speakers are never defined. The first voice begins, “‘Aren’t you sure of what you’re saying? Are you going to change yet again, shift your position according to the questions that are put to you, and say that the objections are not really directed at the place from which you are speaking?…'” and it continues in this accusatory vein.
A second voice then responds, “‘What, do you imagine that I would take so much trouble and so much pleasure in writing, do you think that I would keep so persistantly to my task, if I were not preparing — with a rather shaky hand — a labyrinth into which I can venture, in which I can move my discourse, opening up underground passages, forcing it to go far from itself, finding overhangs that reduce and deform its itinerary, in which I can lose myself and appear at last to eyes that I will never have to meet again. I am no doubt not the only one who writes in order to have no face.'”
The passage is brilliant. Even as he writes about creating a labyrinth, he is in fact creating yet another labyrinth, in this case a labyrinth about identity. Who are these voices? Are they the author? Are they parts of Foucault? Are they just more discourse that unfolds as part of his maze? In one fell swoop, his introduction explodes the notion of the writer, the speaker, the voice of authority. (It is no coincidence that the same year, 1969, he published an essay entitled, “What is an Author?”)
But the passage struck me as relevant to writing code. After all, isn’t writing code “so much trouble and so much pleasure?” Writing code ends up creating labyrinths, which you create and you can easily get lost in. Certainly others reading your code can get lost in your labyrinth, just as you can get lost in others’ code labyrinths when delving into their code. Bizarre internal classes, functions buried inside obscure classes, algorithms that work but your not sure exactly why anymore, “underground passages” and “overhangs”. This is the reality of code as it spirals into more and more complexity, as more hands touch it, the compiler piecing together this patchwork of classes and procedures into a woven executable of dependencies.
What programmers haven’t “lost” themselves in the code, in the best and worst sense of being lost, their very identity usurped by the binary that they created.
Thus, post-structural programming.