[...] Since the massification of computing they have in some small ways also been able to construct themselves in relation to other forms of life. (In the sense that Ludwig Wittgenstein means when he says, "To imagine a language is to imagine a form of life.") This self-sufficiency of software, in such a context, allows (in much the same way as it allows a programmer to think he or she is working on the formulation of a particularly interesting and chewy algorithm when working at another scale, perhaps more determining, on an insurance program to more finely exclude the poor from public services) a certain distance from social or cultural norms. Things can be done in software that don't require much dependence on other factors. [...]

[...] buttons force decisions into binary choices. There is no way of answering that one partially agrees, has not realized the consequences of accepting, or does not care, even though these would probably be franker answers from most users. Buttons are verbs that rule out tenses other than present tense, and rule out modal auxiliary, subjunctive, and other more sophisticated ways in which our language expresses activity. Buttons also designate you as a masterful subject in full control of the situation, which obviously is problematic in many cases, such as the one above, where one cannot oversee, predict, or even understand the consequences of clicking "I accept," [...]

The benefit of these criteria of elegance in programming is that they establish a clear grounding for the evaluation of approaches to a problem. This set of criteria emerging from programming as a self-referent discipline it works on the level of disciplinary formalization, as a set of metrics that allow for a scale of abstraction. This formalization can also be politically crucial as a rhetorical and intellectual device that allows programmers to stake their ground in contexts where they might be asked to compromise the integrity of their work, and something that allows them to derive satisfaction from work that might otherwise be banal.

[...] it is entirely debatable whether framing the issue of machine intelligence in the mirror of the human will allow us to understand what the real problem is. That machines can replace humans tells us nothing special about intelligence, particularly if this is as part of an economy that, in its entropic repetition of the eternally self-same, generally produces stupidity rather than intelligence. [...]

[...] One trains a neural network on specific, finite datasets. The ability to pattern-match more generally presupposes the existence of redundancy in the data and thus self-similarity. So, one could argue that the ability to discern redundancy in data is the ability to learn about how things imitate or repeat themselves (like the data-mining software that tells us which books we want to buy).

For the software designer, programming with interaction involves seeking a kind of magical moment of transformation, a moment when one begins to get back more than what was put in; an unexpected moment when the system seems not only just to work, but to almost come to life; a moment when what had previously been a noisy mess of buggy half-working mechanisms seems to flow together and become a kind of organic whole.

The elusive chase for this kind of transformative moment is the essential reason why geeks keep banging away at their keyboards, deep into the night, deprived of sleep and propped up by caffeine and sugar and the adrenaline of the experience of feeling in contact with something larger than oneself.

If the interrupt teaches us anything about software, it is that software is in many cases only as effective as the people who use it, those mondeterministic machines with their complex, non-reproducible behaviors, those "others" on whom it relies--can it really control such beasts? To understand software in terms of the interrupt is to understand it in terms of its place within larger structures of social formation and governance. Software engineering is simultaneously social engineering. Software criticism, therefore, must also be simultaneously social. In critically engaging with software, we must not only map the vectors of the interrupt, but also seek to make our own interruptions, to pose questions and insert alternative vectors and practices within the assemblages it connects to.