Sleep-workers enquiry - Endnotes

Worker's enquiry in the cynical mode: the unrevolutionary working life of the web developer.

Submitted by ludd on June 28, 2010

This morning, floating through that state between sleep and consciousness where you can become aware of the content of your dreams immediately before waking, I realised that I was dreaming in code again. 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 would drift in and out of sleep when that was my job, and I remember stories from friends of doing an extra shift between going to sleep and waking — of the repetitive beeps of a supermarket checkout counter punctuating the night. But dreaming about your job is one thing; dreaming inside the logic of your job is quite another. Of course it is unfortunate if one’s unconscious mind can find nothing better to do than return to a mundane job and carry on working, 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 habitual, repetitive thought patterns, and the particular logic which I employ when going about my job are becoming hardwired; are becoming the default logic that I think with. This is somewhat unnerving.

The closest thing that I can think of to this experience is that of someone rapidly becoming acquainted with a new language, and reaching that point at which dreams and the rambling thoughts of the semi-conscious mind start to occur in that language. Here too it is a new kind of “logic” that the mind is assuming — that of the structures and patterns of a language, and here too the mind is able to scan across 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 never normally develops 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. That means 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 in a small company, in which I am the main web developer, working alongside one other who also deals with the graphical side. My line manager is the IT manager who, apart from programming himself, takes a lead in organising how our projects come together. Above him are the CEOs, who are a couple of oddball born-again Christians with a serious work ethic. They asked me about my religion in my interview, and set alarm bells ringing straight away. My response was that I didn’t see religion as mere superstition like “banal atheism” does, but that I see it as the real expression of a particular life situation, with its own meaningful content. I could have added that it is the “heart of a heartless world”, but I seemed to have convinced them by that stage that I was a good-ish guy, if not one of them.

After I had worked here for a while the stories started emerging: one of the CEOs claims to be an ex-gangster who saw “the living God” in a bolt-of-lightning revelation when he was contemplating a new scam that involved setting up a fake religion. The other was a successful businesswoman around the dot-com boom, but she fell into a crisis when the father of her child left her, and was converted in a low moment by her new partner — the other CEO. In drunken ramblings at the Christmas do, they have spoken emotively of “the living God”, with that “I was blind but now I can see” way of thinking that is the hallmark of born-agains. They used to try to put all new staff through “The Alpha Course” — a cross-denominational charismatically-inflected project to convert people to Christianity, and to organise monthly “God days” in which all staff would get to take the day off work on the condition that they spend it taking tea with a preacher. Unsurprisingly, many members of staff skipped these days — actually preferring to work than go through some kind of attempted conversion.

They had eased off a little by the time I started — someone had apparently told them that they were at legal risk if they continued to use their business as a missionary organisation. But God still comes to work on a regular basis — intervening to turn the annual business forecast into prophecy, or melding the fortunes of the company with providence. The most notable example for me is the time when I fixed a problem with the speed of our websites. The company had been held up for a while with an appallingly slow performance on each of the many small websites it runs, and people had been searching around for an answer. As long as our performance was that bad, we would’ve only been able to deal with a very limited volume of traffic, and thus a similarly limited number of potential customers. When I figured out the solution the bosses were clearly very happy: suddenly the amount of potential customers we could serve on each site was multiplied by about 30. But rather than thanking me directly, the female CEO simply said that I couldn’t take all of the credit as she’d been praying for better site performance, and we thus had to give God his due. In response I stammered out some over-hasty and awkward attempt at a gag, which trailed into a meaningless murmur.

In an everyday sense, probably the worst part of this job is that I have to deal with the paranoia that comes from knowing that your bosses are insane to the extent that they may not always act in the company’s interest: at least you know where you are with a capitalist who acts with the straightforward rationality of calculated self-interest. When the “living God” takes precedence in deciding company policy, and when stories abound of random and reckless sackings such as that of an employee fired because his wife disagreed with the CEOs’ attitudes towards homosexuality, the sense of a guillotine poised over one’s neck never quite goes away. My line manager is a freakish bipolar who bounces around the office like a well-oiled space hopper one day, and behaves like the drill instructor in Full Metal Jacket the next. But he is decent enough, and easy to deal with once you get to know the cycle.

***

One of the most notable characteristics of the “politics” of this type of job is another kind of bipolarity — the split and antagonism between two poles: the business pole and the technical. The techies always feel that business are making arbitrary decisions based on insufficient knowledge of the way that things really work; that things could be done so much better if only we who understand were left to do it ourselves. Business always feel that the techies are being sticklers, pedants, needlessly and pathologically recalcitrant. Whilst business wishes it could just take flight into the ether, and rid itself of the recalcitrance of its technical staff, the technical staff wish that business would just leave them alone to get the job done properly: that the recalcitrance is that of the real world and its demands. In some ways this makes it easier to deal with the immediate people that I work with: since contact with the business side is mostly supposed to be mediated through a specific “project manager”, I primarily deal with those on my side of the great divide, so it is even possible to develop a certain “us against them” attitude with my line manager, and to hide behind the formal mediations when the shit hits the fan.

This side of the divide we live partially in the worldview of productive capital: business and its needs appear as a parasitic externality imposed upon the real functioning of our great use-value producing enterprise. This side of the divide, we are also 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 provision of real services, of user experiences, and of encouraging the free flow of information. This sometimes spills over into outright conflict with business: where business will be advocating some torturing of language and truth to try to present “the product”, the techies will try to bend the rod back towards honesty, decency, and transparency. “What goes around comes around” seems to be more or less the prevalent attitude in the world of web development in the era after “Web 2.0”: provide the services for free or cheap, give away the information, open everything up, 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 recalcitrance or friction from which it longs to be free, and if a tendency to try to sell snake oil can follow 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.

I am then, under no illusions that the antagonism which inhabits this company provides any ground for romantic revolutionary hopes. The solidarity that we develop against business, apart from providing us with respite and shelter from individualised victimisation, provides a “sanity check” for the company itself. Indeed, the company is well aware of this situation, and this is more or less acknowledged in the creation of a “project manager” role which is explicitly intended for the management of relations between the two sides. The contradiction between technical staff and business is a productive one for capital: the imperative to valorise prevents the techies from going off too far into their esoteric concerns, whilst the basic need for realism is enforced reciprocally upon business by the techies as they insist on the necessity of a more or less “scientific” way of working.

There is little space left in this relation for a wilful “refusal of work”: with the technical, individualised, and project-centred character of the role, absenteeism will only amount to self-punishment where work that is not done now must be done at some point 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. Whilst I used to consider previous jobs as crap places to go to with a hangover, I now find that I must moderate my social life in order not to make working life a misery. Sabotage also, is hardly on the cards, not because of some alleged “pride” which comes with being a skilled worker, but because of the nature of the product that I am providing: whilst sabotage on a production line may be a rational technique, where one’s work resembles more that of the artisan, to sabotage would be to make one’s own life harder. One hears of freelancers and contractors who intentionally write unmaintainable and unmanageable “spaghetti code” in order to keep themselves in jobs. This technique may make sense where jobs rely heavily on particular individuals, but where one works in a typical contemporary development team that employs such group-focused and feedback-centred IT management methodologies 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 simple feelings one might have about doing one’s job well.

Of course, there is that banal level on which I drag myself reluctantly out of bed, strike off as early as I can, and push my luck in terms of punctuality; on which I try to make work time “my time” as much as possible by listening to my iPod while working, sneaking bits of reading time into my working day, or having discreet conversations with friends over the net. This sort of thing is the real fodder of worker’s enquiry. But the bottom-line recalcitrance here is simply that. It is on the same kind of level as the recalcitrance of the human body to work pressure: capital has never been able to make people work a regular 24 hour day — or even close — and people will always test the permissible limits of their own working day. Such is the fundamental logic of the capital-labour relation, and it does not take the pseudo-sociology of a worker’s enquiry to uncover it. Such actions only ever take place in the framework of what is permissible in a given job and, indeed, are defined by this framework. The apparent insubordination of my frequent lateness would soon turn to naught if it threatened my livelihood. And the attendant social pressures that come with this job are such that whatever time I can “claim back” through slack behaviour is more than made up for when the deadline approaches on a project and I work unpaid extra hours into the evening or start work in the middle of the night to fix servers when nobody is using them.

It is only when sickness comes, and I am rendered involuntarily incapable of work, that I really regain any extra time “for myself”. It is a strange thing to rejoice at the onset of the flu with the thought that, in the haze of convalescence, one may finally be able to catch up on a few things that have been pushed aside by work. Here illness indeed appears a “weapon”, but one that fights its own battle, not wielded by the erstwhile aggressor. Yet I wonder sometimes whether this sickness itself can be seen as merely pathological; a contingency imposed upon the body from without. The illness that comes sometimes feels almost willed — a holiday that the body demands for itself. Perhaps there is a continuity between “genuine” illness and the “man-flu” that a matronly temping agent once accused me of when I wilfully ducked out of work for a week on hammy claims to terrible sickness. It is at least certain that if sickness is all that we have, there is little hope here for meaningful “resistance.”

***

If then, worker’s enquiry is about unearthing a secret history of micro-rebellions, exposing the possibilities for struggle in the fine grain of lived experience, and in the process, bringing consciousness of this to oneself as well as other workers, this is worker’s enquiry in the cynical mode. We “struggle”. We are recalcitrant. But as techies against business our struggle and our recalcitrance are integral to the movement of capital, and as workers against capital our struggle has absolutely no horizon and, indeed, is barely struggle at all. Our day-to-day interest as workers is, in the most part, practically aligned with that of this particular capital. If programmers are a vanguard in the enshrinement of use-value, of technological libertarianism, of collaborative work, of moralistic “best-practices”, of the freedom of information, it is because all of these things are posited as necessary in the movement of capital. The systematic normativity with which our working practice is shot through is merely a universalisation of capital’s own logic.

Just as social capital posits its own constraint in the form of the state in order to not destroy itself through the rapacious self-interest of each individual capital, after an early period of ugly coding due to the fragmentation of the internet into a babel of different platforms, browsers and languages, a consensus formed in the development world that “standards” were important. Central to these standards is an idea of universalism: anything that adheres to these standards should work and be supported. If you don’t adhere to these standards, you are asking for trouble, and it is your own fault if you find yourself pissing your capital away up a technological back-ally. Microsoft became a pariah due to their continual contempt for these standards, and their penchant for developing proprietary annexes on the great public space of the net. Developers began to proudly sport web standards badges on their personal sites, and to become vocal advocates of technologies like Mozilla’s “Firefox” which, apart from the fact that it is “open source”, always beat Internet Explorer hands-down in terms of standards-compliance. Standards became enshrined in the moral universe of the developer, even above open source. To adhere to standards is to take the standpoint of a moral absolute, whilst to diverge from them is a graceless fall into the particularistic interests of specific groups. The universalisability of working practices became the particular imperative of informational capital; a duty to the “invisible church” of the internet.

***

Whilst some of these traits that come with the particularly collective character of work do not occur in the same way for the freelancer, “being your own boss” tends to amount literally to imposing upon oneself what can otherwise be left to others. I have worked freelance a little before this job, and also in my spare time whilst doing this job, and the very thought of such work now causes my soul to whither a little. In freelancing, one can easily end up working uncountable hours, fiddling with projects in one’s “own” time, with work colonising life in general due to the inevitable tendency to fail to self-enforce the work/life separation that at least guarantees us a fleeting escape from the lived experience of alienated labour. At least, when I walk out of the office I enter the world of non-work.

Indeed, the hardened work/life separation of the Mon-Fri 9-5 worker looms increasingly large in the totality of my experience. Whilst Sunday is a gradual sinking into the harsh knowledge that the return to work approaches and a sometimes dragging of the dregs of the weekend into the wee small hours of the morning, Friday evening is the opening of a gaping chasm of unquenchable desire, and the desperate chasing after satisfaction whose ultimate logic is also that of boozey self-annihilation. I become increasingly a hedonistic caricature of myself, inveighing against others to party harder, longer, and blowing much of my free time away in a fractured, hungover condition. This is the desiring state of the old fashioned rock’n’roller: the beyond of work as a state of pure transcendent desire and consumption, the nothingness of a pure abstract pleasure beyond the mere reproduction of labour-power. The refusal to merely reproduce ourselves as workers coupled to a desire to annihilate ourselves as humans. This is what the Stooges’ “1970” means.

***

But when I’m lying in that splintered early morning consciousness the night after partying, slipping in and out of dreams, and as the previous night’s fleeting attempt at liberation recedes, I often find that I am dreaming in code. It can be one of various kinds of code — any of those that I work with. A sequence will pop into my head and rattle around, unfolding itself as it goes, like a snatch of melody or conversation repeating itself in your ears. Much of the time, if I was conscious enough to re-examine it, it’d probably be nonsense: I have enough difficulty dealing with the stuff when I’m awake, and I suspect that my unconscious mind would fare little better. But sometimes it is meaningful.

One morning recently I awoke with the thought of a bug in some code that I had written — a bug which I had not previously realised was there. My sleeping mind had been examining a week’s work, and had stumbled upon an inconsistency. Since I am a thought-worker, and since the identification and solution of such problems is the major aspect of my job, it is not that fantastical to say that I have been performing actual labour in my sleep. This is not the magical fecundity of some generalised creative power, churning out “value” somehow socially, beyond and ontologically before the labour process. It is actual work for capital, indistinguishable in character from that which I perform in my working day, but occurring in my sleeping mind. Suddenly the nightmarish idea of some new kind of subsumption — one that involves a transformation of the very structures of consciousness — begins to look meaningful. Indeed, I find that standard paths of thought seem increasingly burned into my mind: the momentary recognition that there is a problem with something prompts a fleeting consideration of which bit of code that problem lies in, before I consciously jolt my mind out of code-world and into the recognition that “bugfixing” does not solve all problems. Comical as it sounds, there is something terrifying here.

Beyond the specific syntax of a language, isn’t it a particular logic, or way of operating that is brought into play when one thinks in this way? It is one that I suspect is not neutral: the abstract, instrumental logic of high-tech capitalism. A logic of discrete processes, operations, resources. A logic tied to particular “ontologies”: the objects, classes, and instances of “object-oriented programming”, the entities of markup languages like HTML. This is the logic which increasingly inhabits my thought. And when thought becomes a mode of activity that is productive for capital — the work for which one is actually paid — when that mode of activity becomes a habit of mind that springs into motion “as if by love possessed”, independent of one’s willed, intentional exertion, doesn’t this prompt us to wonder whether the worker here is entirely the bourgeois subject that capital always summoned to the marketplace: whether the subject of this labour process is the centred individual who would set about making his own world if it were not for the alienating, abstractive power of value? When I find myself observing myself sleep-working, I observe myself acting in an alienated way, thinking in a manner that is foreign to me, working outside of the formal labour process through the mere spontaneous act of thought. Who is to say that the overcoming of this “alienation” will not be that language taking its place as mother-tongue: that alienation will not entirely swallow that which it alienates?

If the workplace here is the forlorn site, no longer of that exteriority of the worker in which it is meaningful and possible to commit daily acts of insubordination, to develop a sense of a latent “autonomy” posited in the very exteriority of the worker to the process of production, but of a productive antagonism in which technical workers give capital its “sanity check” and in which recalcitrance is merely that of the bodiliness of these materials through which capital flows; and if labour becomes a mere habit of thought that can occur at any time — even in sleep — what hope is there here for the revolutionary overcoming of capitalism? What does our revolutionary horizon look like? It must surely appear foolish to place any hope — at least in an immediate sense — in the nature of this mental work and its products, in the internet or in “immaterial labour”

from http://endnotes.org.uk/

Comments

klas batalo

13 years 8 months ago

In reply to by libcom.org

Submitted by klas batalo on June 28, 2010

this is originally from DISSIDENT #3 by the Batko Group is it not? though this might be an edited/translated version?

Mike Harman

13 years 8 months ago

In reply to by libcom.org

Submitted by Mike Harman on June 28, 2010

While I don't agree with the pessimistic conclusions too much, the "thinking/dreaming about/in code", specifics of the conflicts between developers and management, the emphasis on standards / clean code, difficulties with slacking and the fact that all the 'good things' coming out of software development are driven by and needed by capital are spot on.

Steven.

13 years 8 months ago

In reply to by libcom.org

Submitted by Steven. on June 28, 2010

I like this article a lot, from the personal point of view. (Is the author credited anywhere?)

As for the conclusions, while I don't necessarily disagree with them, but they seem to be responding to a statement I'm not sure anyone would make - seemingly that the professional role of web developer has some inherent tendency to undermine the rule of capital.

The article argues convincingly that this is not the case - but whoever said that it was?

Also, I feel that it hints at some parts of the job as being specific to web developers, whereas actually I think they are pretty universal. Particularly with regard to workers caring about standards and rationality, against often managements irrationality and inefficient ways of doing things. In my job in admin/clerical work we all experience the same thing - often management directives are stupid, irrational, inefficient etc and sometimes we will struggle to do things in a better way. In many instances this is just simply because when you do a job for a long time often you do get some sort of sense of pride in your work, no matter how futile it is. But of course, mostly this just ends up helping the bosses profits/efficiency, so doesn't undermine capital.

Importantly, the author seems to state that the "refusal of work" is not a possibility in this sector. The author gives the example of bunking off work or slacking, and stating that these are both counterproductive as it lets others in the team down, and ultimately just creates more work for yourself later.

Again, this is not something specific to IT, but is the case with most jobs. The important thing which is missing from the author's argument is the collective aspect. Individual refusal of work is never going to be able to achieve much. Where there is revolutionary potential, however, is in the collective refusal of work. This can be done in small steps, for example a team of workmates collectively slowing their rate of work, or over-estimating the amount of time it would take them to complete a project before beginning it. And if workers are more confident you can get situations of mass absenteeism. See these examples from the Solidarity pamphlet on the Lordstown struggle:

Another yardstick of changing attitudes to work is provided by the figures for absenteeism At GM absenteeism jumped from 2% in 1960 to 6% in 1970 ('GM:The Price of Being Responsible', Fortune, January 1972). It rose another 11%, in 5 months, in early 1972. According to Malcolm L. Denise, Vice President of Labour Relations at Ford Motor Company, the rate of absenteeism for hourly-rated workers at Ford in the USA 'more than doubled' between 1960 and 1968. Every day at GM 5% of workers are absent 'with no explanation whatsoever' - On Mondays and Fridays the percentage doubles, 10% are out (Fortune, June, 1970). The Wall Street Journal of September 29, 1970 quoted a GM statement: 'many workers who become ill in midweek don't come back to work till the following Monday. Now it's just not normal that everybody should recover the same day!' At Chrysler absenteeism has reached 18.6%. During the summer months, at Lordstown, it had reached as high as 20%. When a worker at Lords town was asked 'What is it like on a Monday, in summer, then?', he replied, 'I don't know, I've never been in for one'. (Sunday Telegraph, December 2, 1973) Another worker, when asked 'how come you're only working four days a week?' replied, 'because I can't make enough money in three'. (Newsweek February 7, 1973)

http://libcom.org/library/lordstown-struggle-ken-weller

On sabotage, again it is stated that sabotage is not helpful. Firstly, sabotage is not necessarily something destructive, it can just be any subversion of work processes to your own ends. Many examples like this, including from the IT sector, are in the excellent book Sabotage in the American workplace, by Martin Sprouse, of which we have extracts in our library here: http://libcom.org/tags/sabotage

Secondly, for most people physically sabotaging their work is pointless counterproductive much of the time. However, sabotage can be used to lever gains from management. Thinking of specific possibilities, I admit that I don't know much about the profession, but wouldn't it be possible to deliberately code something incorrectly, while storing a correct version, and later having to "take time to fix the problem", in which you could do whatever you wanted, as you already knew what the problem was and could fix it immediately. Just a thought...

Anyway, overall very interesting article I thought.

ludd

13 years 8 months ago

In reply to by libcom.org

Submitted by ludd on June 29, 2010

I like this article a lot. I work as a web developer and I frequently experience work colonizing my mind in a way that seriously troubles me. Phrases like "business processes" come to mind. Before this, I have worked few manual jobs which were more miserable though they left feeling me more sane. Like the author several times I felt that I get sick exactly at the point where I can't take work anymore. The stuff about open standards, the progressive aspect of our work serving capital, the drawbacks of slowdowns all rings very true.

My biggest problem with it is similar to what Steven and Mike already mentioned. The article says that our interests are practically aligned with some particular capital. This is true, but I don't see how it is different from other kinds of workers who can't easily find a replacement job. Their survival depends on successful profit making by "their" capital. All worker resistance ultimately get integrated into capital as long as capital exists and in a way drives it forward. So, imho, there is nothing especially un-revolutionary about web developers or revolutionary about textile workers (who sometimes form trade unions that manage them and sometimes burn down factories). Though I think that more privileged workers are less likely to rebel.

I admit that I don't know much about the profession, but wouldn't it be possible to deliberately code something incorrectly, while storing a correct version, and later having to "take time to fix the problem", in which you could do whatever you wanted, as you already knew what the problem was and could fix it immediately. Just a thought...

Everywhere I've worked as a programmer (not just web, but video games and business software) I've never met anyone who would openly suggest breaking code on purpose. Techies, who spend all their time fixing things, would think that was some kind of irrational crime, so collectively it wouldn't fly unless the struggle between them and management was very heated to a point where more direct slowdowns were already practiced. I think in that environment it would be possible to break things in a way that was simple for programmers to fix (wouldn't even need writing down), but hard for management to find.

You can also find stories about individual pissed off sysadmins planting "logic-bombs" in revenge. Though most of them get caught and convicted.

Finally, I couldn't find the author's name anywhere on the Endnotes site.

Submitted by Mike Harman on June 29, 2010

Steven.

Again, this is not something specific to IT, but is the case with most jobs.

Yeah I completely agree, it manifests itself slightly differently with web development - you generally have a quite finite goal compared to other jobs I've worked (it might keep changing every five minutes but that's a different issue) but depending on how the work is done, it can take 100 hours or 1000 hours to end up with exactly the same functionality.

Steven.

The important thing which is missing from the author's argument is the collective aspect. Individual refusal of work is never going to be able to achieve much. Where there is revolutionary potential, however, is in the collective refusal of work. This can be done in small steps, for example a team of workmates collectively slowing their rate of work, or over-estimating the amount of time it would take them to complete a project before beginning it.

I've definitely seen this (and do it) but again it's a bit complicated.

A lot of web development projects are done for external clients - a company builds websites, another company hires them to build their website (or is subcontracting from another company etc.). When a project first comes through, a developer - sometimes one in a management position but not necessarily, gets the request for proposals and tries to figure how long the job will take in hours. On that level it makes sense to estimate everything as high as possible (while still being believable) because working on something that starts off under-budget is just nasty. But you're doing a favour for the company when you do that, because they won't end up doing work they can't bill, or having to chase the client for extra cash etc. whereas at the beginning of the project they instantly forget about all the overbudget / late paying nightmares they still haven't completely finished from last time.

On the other hand, once a project starts, there's a constant stream of requests for changes and new features which come through (in this case doesn't matter if it's for an external client or an internal project), the term for this is scope creep. Every single change, unless it-s dropping something completely (and even in that case sometimes if it's already half built), means more work for the development team. Since with the vast majority of projects the budget is already more or less fixed, and if not the budget, then definitely the schedule, scope creep only means:

1. paid overtime (about the best outcome)
2. unpaid overtime
3. extra people get hired to take on the extra work - which can be good in some cases but there's also entire books written about how it's bad most of the time.
4. project goes over deadline and/or budget - who this hits worst is depends on a lot of factors, this usually happens along with various combinations of 1-3 anyway with nearly any software project.

So at this stage, there is a bit of a potential for refusing work - you can exaggerate how hard it is to implement, point out that it's going to break the site etc. etc. usually this is all true to various extents anyway (and therefore part of the sanity check mechanism) but it also affects workload directly, and I've seen people respond completely differently to requests with vastly different results. Sometimes the change will get pushed out until later, sometimes the feature gets reduced massively to something which can be done much easier, sometimes there's deadlock, but even in that last case you've just made it harder for them to ask for the next one. Even if we accept all this is firmly within the overall capitalist process, it's still worth doing though - similar level to a health and safety rep in other industries.

And if workers are more confident you can get situations of mass absenteeism. See these examples from the Solidarity pamphlet on the Lordstown struggle:

How effective this is would depend on the situation - a lot of people are paid hourly and if legally self-employed then no sick pay, work remotely - so they'll notice a drop in productivity but unless you're physically in bed they know you'll likely check e-mail at least once a day etc. - and that's how they get hold of you anyway, as opposed to not going into an office when you normally get forgotten about by people who are used to having you a short walk away instead of at the other end of their internet connection. But yeah done en masse it could have an effect.

On sabotage, again it is stated that sabotage is not helpful. Firstly, sabotage is not necessarily something destructive, it can just be any subversion of work processes to your own ends. Many examples like this, including from the IT sector, are in the excellent book Sabotage in the American workplace, by Martin Sprouse, of which we have extracts in our library here: http://libcom.org/tags/sabotage

Secondly, for most people physically sabotaging their work is pointless counterproductive much of the time. However, sabotage can be used to lever gains from management. Thinking of specific possibilities, I admit that I don't know much about the profession, but wouldn't it be possible to deliberately code something incorrectly, while storing a correct version, and later having to "take time to fix the problem", in which you could do whatever you wanted, as you already knew what the problem was and could fix it immediately. Just a thought...

There are some well known examples like http://en.wikipedia.org/wiki/Sim_copter#Controversy (linked from Django on another thread).

Also a lot of small examples on thedailywtf - http://thedailywtf.com/Articles/Thats-One-Way-to-Fulfill-a-Requirement.aspx and http://thedailywtf.com/Articles/The-Speedup-Loop.aspx for example. And not necessarily sabotage but http://thedailywtf.com/Articles/Special-Delivery.aspx is classic. That site veers between posts like those and "look how incompetent my co-worker is!" though, the testing one is in-between.

The article's right to say there's tendencies against this though - for example with open source you don't just have your supervisor and workmates potentially coming across code, there's also potentially hundreds of people who might read it. Also when you have a large team working on the same code base, it's possible for one person to introduce a bug one day, then the next person spend 8 hours the next day trying to track it down - and they'll only know who's fault it is after spending the 8 hours (the command for figuring out who's responsible for a code change is actually called 'blame' - which shows the last change to the line and how made it - you generally arrive there /after/ hours of banging your head against a wall - so someone who always shows up there is going to get less and less popular with their workmates). But all this would really depend on specifics.

Submitted by Kim Müller on September 11, 2010

Sabotage:
This is originally written in english, but it was translated and published in swedish, both in Dissident and on blogs over two years ago.

Steven.

13 years 5 months ago

In reply to by libcom.org

Submitted by Steven. on October 1, 2010

was reading the Aufheben article on Negri and Hardt the other day and it reminded me of my comment on this article, when I said this:

As for the conclusions, while I don't necessarily disagree with them, but they seem to be responding to a statement I'm not sure anyone would make - seemingly that the professional role of web developer has some inherent tendency to undermine the rule of capital.

The article argues convincingly that this is not the case - but whoever said that it was?

I had read Empire years ago, but had forgotten about how talk of "immaterial labour" talks about how such labour can be autonomous of or even antagonistic to capital, so I realise now that this article was arguing against that perspective, and doing so pretty well, but I think that perspective is already pretty clearly incorrect.

Craftwork

7 years 9 months ago

In reply to by libcom.org

Submitted by Craftwork on June 7, 2016

The author is one of the Endnotes group. Admin; author's name removed. Please do not post real names without author's permission.