Software Engineer's Simple Sabotage Field Manual
The Office of Strategic Services is hereby thanked and credited with providing the template for this manual.
And ye shall know the truth and the truth shall make you free
The contents of this Manual should be carefully controlled and should not be allowed to come into unauthorized hands.
The instructions may be sent via Slack, or anonymously via email, but should be distributed with care and not broadly. They should be discussed over message boards and podcasts only in limited capacity.
The sabotage described herein requires no destructive tools whatsoever and does not produce physical damage. It is based on universal opportunities to make faulty decisions, to adopt a noncooperative attitude, and to induce others to follow suit. Making a faulty decision may be simply a matter of miscategorising a JIRA ticket, running the wrong Jenkins pipeline or deploying the wrong version of a service to production. A non-cooperative attitude may involve nothing more than creating an unpleasant situation among one's fellow workers, engaging in bickering, or displaying surliness and stupidity.
The potential engineer-saboteur should discover what types of faulty decisions are normally made in his kind of work and should then devise his sabotage so as to enlarge that "margin of error".
Acts of simple sabotage are occurring throughout the corporate world. An effort should be made to add to their efficiency, lessen their detectability, and increase their number. Acts of simple sabotage, multiplied by thousands of engineers, can be an effective weapon against the corporations. Occurring on a wide scale, simple sabotage will be a constant tangible drag on the profit seeking efforts of the corporations.
Widespread practice of simple sabotage will harass managers, executives and HR departments. Further, success may embolden the engineer eventually to find colleagues who can assist him in sabotage of greater dimensions.
Motivating the Engineer-Saboteur
Simple sabotage is often an act which the engineer performs according to his own initiative an inclination. Acts of destruction do not bring him any personal gain and may be completely foreign to his good-natured disposition. Purposeful stupidity is contrary to human nature. He (the would-be engineer-saboteur) frequently needs pressure, stimulation or assurance, and information and suggestions regarding feasible methods of simple sabotage.
The ordinary engineer very probably has no immediate personal motive for committing simple sabotage. Instead, he must be made to anticipate indirect personal gain, such as might come with his inept manager being fired, replacement of incompetent technical leads, or no longer having to deal with an overbearing Product Manager. Gain should be stated as specifically as possible: simple sabotage will hasten the day when manager X and his lackeys Y and Z will be thrown out, when particularly obnoxious late-in-the-day meetings will be cancelled, when new technologies will be adopted, and so on. Abstract verbalizations about personal liberty, correct decision making processes etc. will not be convincing in most companies. In many places they will not even be comprehensible.
Since the effect of his own acts is limited, the engineer-saboteur may become discouraged unless he feels that he is a member of a large, though unseen, group of engineer-saboteurs operating against the corporation or the management. Estimates of the proportion of the population engaged in sabotage should be disseminated. Instances of successful sabotage already are being talked over in hidden Slack groups, and this should be continued and expanded where compatible with security.
Most important of all would be to create a situation in which the engineer-saboteur acquires a sense of responsibility and begins to educate others in simple sabotage.
Encouraging Destructiveness
It should be pointed out to the engineer-saboteur that he is acting in self-defense against self-serving and often unqualified managers, or is retaliating against the company/corporation for other acts of abuse and exploitation. A reasonable amount of humor in the presentation of suggestions for simple sabotage will relax tensions of fear.
Where the engineer-saboteur formerly kept shell scripts clean and readable, he should now let them deteriorate into illegible mess (usage of Perl is encouraged); Libraries that formerly were well-maintained and had clear READMEs should now be denied pull-requests and fixes for unclear reasons, and have the (badly mangled) documentation spread across multiple, hard to find, Confluence pages; normally diligent, he (the engineer-saboteur) should now be lazy and careless; and so on. A state of mind should be encouraged that anything can be sabotaged.
Safety Measures
The amount of activity carried on by the engineer-saboteur will be governed not only by the number of opportunities he sees, but also by the amount of pressure he feels from management. Simple sabotage will be discouraged if too many simple engineer-saboteurs are disciplined or fired.
Try to commit acts for which several people could be responsible. For instance, if you are performing a complex merge, you can ask for the assistance of your colleagues, and then introduce subtle bugs into the code that is being merged. Such mistakes are common, and the errors are almost impossible to attribute to any one individual, as the situation involves multiple mergers and committers. In another instance, one can blame the Product Manager for poorly written JIRA ticket with unclear specifications which lead to wasting several weeks on implementing the wrong feature. And so on.
Do not be afraid to commit acts for which you might be blamed directly, so long as you do so rarely, and as long as you have a plausible excuse: you made a bad commit because you were under pressure to deploy the feature and it was late in the evening; you deployed the wrong version because the version list isn't sorted alphanumerically; you merged the commit into main branch because you were sure it was just a simple fix that didn't warrant re-running the test suite. Always be profuse in your apologies. Frequently you can "get away" with such acts under the cover of pretending stupidity, ignorance, over-caution, fear of being suspected of sabotage, or weakness and dullness due to working too many hours.
After you committed an act of easy sabotage, resist any temptation to wait around and see what happens. It's best to go on a coffee break, or simply to go home. Best of all is to go on a vacation. Of course, there are circumstances when it would be suspicious for you to leave. Apply common sense.
General Devices for Lowering Morale and Creating Confusion
Give lengthy and incomprehensible explanations when questioned.
Report imaginary sexual harassments and personal insults to HR.
Act stupid.
Be irritable and quarrelsome as possible without getting yourself into trouble.
Misunderstand all sorts of regulations concerning such matters as bug reporting, task prioritization, code naming conventions, etc.
Constantly complain that the coffee is terrible and the machine is dirty. Caution others against using it.
In public treat middle management and C-level executives coldly.
Stop all conversation when a manager or an executive is near you.
Take people out on coffee breaks and complain about how stupid the management is, and how terrible everything is. Encourage them to quit.
Cry and sob hysterically in bathroom stalls.