This morning, floating through that state between sleep and consciousness in which you can become aware of your dreams as dreams immediately before waking, I realized that I was dreaming in code again.footnote1 This has been occurring on and off for the past few weeks; in fact, most times I have become aware of the content of my unconscious mind’s meanderings, it has been something abstractly connected with my job. I remember hearing the sound of the call centre in my ears as I drifted in and out of sleep when I was working there, and have heard stories from friends of doing an extra shift between going to sleep and waking—the repetitive beeps of a supermarket checkout punctuating the night. But dreaming about your job is one thing; dreaming inside the logic of your work is quite another. Of course it is unfortunate if one’s unconscious mind can find nothing better to do than return to mundane tasks, or if one’s senses seem stamped with the lingering impression of a day’s work. But in the kind of dream that I have been having the very movement of my mind is transformed: it has become that of my job. It is as if the repetitive thought patterns and the particular logic I employ when going about my work are becoming hardwired; are becoming the default logic that I use to think with. This is somewhat unnerving.
The closest analogy may be that of someone rapidly becoming acquainted with a new language, and reaching the point at which dreams and the rambling thoughts of the semi-conscious mind start to occur in that tongue. Here too it is a new kind of ‘logic’ that the mind is assuming, and again the brain is able to scan its own processes with a pseudo-objectivity and determine the nature of their logic as something particular—something which does not yet possess the whole mind, but inhabits it and takes command of its resources. One never really gains this kind of perspective on thoughts in one’s own language; one does not usually develop an awareness of the particularity of one’s own thought. But right now I experience it as a clear split: that between the work-logic me, and the spectator-on-that me.
I work in it. Specifically I am a web developer, which means that I write potentially all the original code that goes into a website: markup like html and xml, the visual styling, the functional ‘logic’ that happens behind the scenes and in your web browser, and the scripts that keep a site running on a web server. I work for a small e-commerce start-up that specializes in the difficult business of selling second-hand cars online. The company is a late echo of the dot.com bubble, in which one of the ceos originally made the practically inexhaustible funds that keep this unprofitable enterprise afloat. I am the main web developer, working alongside another who also deals with the graphical side. My line manager is the it manager who, apart from programming himself, takes a lead in organizing how our projects come together. Above him are the ceos, a couple of oddball born-again Christians with a serious work ethic. They used to try to put all new staff through the Alpha Course, a charismatically inflected Christian-recruitment project, and to organize monthly ‘God days’ when all staff would get to take the day off work, on condition that they spend it taking tea with a preacher. Unsurprisingly, many employees skipped these—actually preferring to work rather than go through the motions of religious conversion.
One notable characteristic of the ‘politics’ of the job is the split—or antagonism—between the business pole and the technical one. The techies always feel that business are making arbitrary decisions, based on insufficient knowledge of the way things really work; everything could be done so much better if only we, who understand the task in hand, were left to do it by ourselves. Business always feel that the techies are being sticklers, pedants, needlessly or pathologically recalcitrant, while the technical staff feel the recalcitrance is that of the real world and its demands. In some ways this makes it easier for me: since contact with the business side is mostly mediated through a specific ‘project manager’, and I primarily deal with those on my side of the great divide, it is even possible to develop a certain ‘us against them’ attitude.
From our point of view, business and its needs appear as parasitic externalities imposed upon the real functioning of our use-value-producing enterprise. We are strangely tied to a certain normativity; not just that of doing the job right in a technical sense, but also that of thinking in terms of the provision of real services, of user experiences, and of encouraging the free flow of information. This sometimes spills over into outright conflict: when business advocates some tortuous use of language to hype ‘the product’, the techies will try to bend the stick back towards honesty and transparency. ‘What goes around comes around’ seems to be the prevalent attitude in web development in the era after ‘Web 2.0’: provide the services cheap or free, give away the information, be decent and hope that somehow the money will flow in. If business acts with the mind of money capital, encountering the world as a friction or recalcitrance which it longs to overcome, and if a tendency to try to sell snake oil follows from that, in the strange world where technical pride opposes itself to capital as capital’s own developed super-ego, use-value rules with a pristine conscience; everything is ‘sanity checked’—to use the terminology of my boss—and the aggregation of value appears as an accidental aside.
Distrustful of trade-union bureaucracy, the Italian operaisti of the 1960s hoped to discover opportunities for working-class autonomy within the production process itself, through the form of the ‘worker’s enquiry’. Examining the business–technical antagonism in web development today, though, yields scant grounds for revolutionary optimism. The solidarity that we develop against business, apart from providing us with respite and shelter from individualized victimization, functions as a ‘sanity check’ for the company itself. The contradiction between technical staff and business is a productive one for capital: the imperative to valorize prevents the techies from wandering off into their esoteric concerns, while the need for realism is reciprocally enforced by the techies as they insist on a broadly ‘scientific’ way of working.
There is little space left in this relation for a wilful ‘refusal of work’: given the individually allocated and project-centred character of the job, absenteeism only amounts to self-punishment, as work that is not done now will have to be done later, under greater stress. Apart from that, there is the heavy interpersonal pressure that comes with the role: since a majority of the work is ‘collaborative’ in a loose sense, heel-dragging or absenteeism necessarily involves a sense of guilt towards the technical workers in general. Nor is sabotage a creative option here; not because of the supposed pride of the skilled worker, but due to the nature of the product. On a production line, sabotage may be a rational tactic, halting the relentless flow to provide half-an-hour of collective sociability. When one’s work resembles that of the artisan, to sabotage would be to make life harder. Occasionally one hears of freelancers or contractors who write confusing and idiosyncratic ‘spaghetti code’ in order to keep themselves in work. This technique may make sense when a company relies heavily on particular individuals; but in a typical development team, which uses feedback-centred it management methodologies such as ‘agile’ and ‘extreme’ programming, and where ‘ownership’ of a project is always collective, high-quality, clearly readable code has a normative priority that goes beyond whatever feelings one might have about doing one’s job well.