A lot of these read more like workplace complaints and poor management processes. The point of the original was how an individual already on the system could pe

A lot of these read more like workplace complaints and poor management processes. The point of the original was how an individual already on the system could perform small acts of sabotage. My list would be: 1) overestimate small tasks 2) Corollary to #1, underestimate large tasks 3) Find reasons to take the overestimated tasks and perform them slowly 4) Encourage your colleagues to take the larger tasks 5) Encourage bike shedding. Frequently evaluate your code standards. 6) If you are in the position to do so, enforce a terrible naming standard. 7) Write slow tests 8) Write useless tests 9) If you notice a coverage gap, try to introduce a subtle bug As a manager: 1) Discourage specialization in favor of "flexibility" 2) Assign tasks to those with the least domain knowledge, within reason 3) Avoid letting more than a single developer work on a particular system/increase the "bus factor" 4) If you are able, under promise and under deliver 5) When brought new ideas or are asked to use new tools, be very encouraging but say you need approval. Never ask for approval.