The Coders Programming Themselves Out of a Job
In 2016, an anonymous confession appeared on Reddit: “From around six years ago up until now, I have done nothing at work.” As far as office confessions go, that might seem pretty tepid. But this coder, posting as FiletOFish1066, said he worked for a well-known tech company, and he really meant nothing. He wrote that within eight months of arriving on the quality-assurance job, he had fully automated his entire workload. “I am not joking. For 40 hours each week, I go to work, play League of Legends in my office, browse Reddit, and do whatever I feel like. In the past six years, I have maybe done 50 hours of real work.” When his bosses realized that he’d worked less in half a decade than most Silicon Valley programmers do in a week, they fired him.
The tale quickly went viral in tech corners of the web, ultimately prompting its protagonist to delete not just the post, but his entire account.
About a year later, someone calling himself or herself Etherable posted a query to Workplace on Stack Exchange, one of the web’s most important forums for programmers: “Is it unethical for me to not tell my employer I’ve automated my job?” The conflicted coder described accepting a programming gig that had turned out to be “glorified data entry”—and, six months ago, writing scripts that put the entire job on autopilot. After that, “what used to take the last guy like a month, now takes maybe 10 minutes.” The job was full-time, with benefits, and allowed Etherable to work from home. The program produced near-perfect results; for all management knew, its employee simply did flawless work.
The post proved unusually divisive, and comments flooded in. (As of October 2018, it’s been viewed nearly half a million times.) Reactions were split between those who felt Etherable was cheating, or at least deceiving, the employer, and those who thought the coder had simply found a clever way to perform the job at hand. Etherable never responded to the ensuing discussion. Perhaps spooked by the attention—media outlets around the world picked up the story—the user vanished, leaving that sole contribution to an increasingly crucial conversation about who gets to automate work and on what terms.
Call it self-automation, or auto-automation. At a moment when the specter of mass automation haunts workers, rogue programmers demonstrate how the threat can become a godsend when taken into coders’ hands, with or without their employers’ knowledge. Since both FiletOFish1066 and Etherable posted anonymously and promptly disappeared, neither could be reached for comment. But their stories show that workplace automation can come in many forms and be led by people other than executives.
***
The promise of automation, touted by optimistic economists and sanguine futurists, has been that yielding work to machines would eliminate the drudgery of mindless, repetitive labor, freeing humans to fill our days with leisure, creative pursuits, or more dynamic work. In 1930, John Maynard Keynes famously speculated that “automatic machinery and the methods of mass production” would help deliver a 15-hour workweek—and even those hours would only be necessary to help men feel they had something to do.
Nearly a century later, despite formidable advances in technology, repetitive tasks persist. Automation continues apace; millions of jobs once carried out by humans are accomplished by software and mechanized factories, while Americans are working harder and increasingly longer hours. The gains from automation have generally been enjoyed not by those who operate the machines, but by those who own them. According to the Organisation for Economic Cooperation and Development, the share of income going to wages in OECD nations has been decreasing since the 1970s, while the share being funneled into capital—into things like cash reserves and machinery—has been increasing. It can seem that some of the only workers who have realized any scrap of that rusty old promise of automation are the ones who’ve carved out the code to claim it for themselves.
Programmers, of course, have been writing code that automates their work for decades. Programming generally involves utilizing tools that add automation at different levels, from code formatting to merging to different code bases—most just don’t take it to the extreme of fully or nearly fully automating their job. I chatted, via direct message on Reddit and email, with about a dozen programmers who said they had. These self-automators had tackled inventory management, report writing, graphics rendering, database administration, and data entry of every kind. One automated his wife’s entire workload, too. Most asked to remain anonymous, to protect their job and reputation.
“When I started, my job literally took me eight hours a day,” an early self-automator, whom I’ll call Gary, told me. He worked for a large corporate hotel chain that was beginning to computerize its workflow in the ’90s. Gary quickly recognized that he was spending a lot of his time repeating the same tasks, so he started learning to code after-hours. “Over the course of about three months, I built a piece of code in Lotus [1-2-3, then a popular PC spreadsheet program] that not only automated individual repetitive tasks, it effectively automated the entire job,” he says. He didn’t tell his bosses exactly what he had done, and the quality of his working life improved considerably.
“It felt weird to have free time during the day,” he told me. “I spent that time learning about the other systems in the hotel.” He then made himself useful, helping management with bottlenecks in those systems. Auto-automation had erased menial toil, reduced his stress, and let him pursue his actual interests. “In effect, I made my position into something I love, which is troubleshooting,” he says. Two weeks before he left, he handed his boss a diskette loaded with the program and documentation on how it ran. His boss was upset that he was quitting, Gary says—until he handed over the diskette, showed him how the program worked, and told him to call if there was ever any problem. No call ever came.
Todd Hilehoffer was compiling reports for a Pennsylvania insurance company in 2000 when he realized his work could be done by a computer program. “I was very green at the time, with only a year of IT experience,” he told me in a direct message, when he started writing code that could replace his job. “It took me about a year to automate it. I always thought my bosses would be impressed and would find more work for me.” They were impressed, but they also didn’t have another job for him. He passed his days playing chess online. “I was really only completely idle for about 6-9 months,” Hilehoffer writes, after which he received a promotion.
In most fields, workers rarely have any formal input into whether their job is automated, or how and when automation could be implemented. Self-automators offer a glimpse of what it looks like when automation is orchestrated not by top-down corporate fiat, but by the same workers who stand to reap its benefits. Some embrace the extra leisure time, while others use the spare hours to learn new skills and tackle new programmatic challenges.
“What I quite like about these stories is that it shows that automation still has the potential to reduce the amount of boring work we have to do,” Jamie Woodcock, a sociologist of work at the Oxford Internet Institute, told me. “Which was the promise of automation, which was that we wouldn’t have to work 60-hour workweeks, and we could do more interesting things like stay home with our kids.”
Yet many self-automators are afraid of sharing their code outside the cubicle. Even if a program impeccably performs their job, many feel that automation for one’s own benefit is wrong. That human labor is inherently virtuous—and that employees should always maximize productivity for their employers—is more deeply coded into American work culture than any automation script could be. And most employment contracts stipulate that intellectual property developed on company time belongs to the employer. So any efficiency hack or automation gain an employee might make is apt to be absorbed by the employer, the benefits rerouted upstream.
One coder described keeping the fact that he’d fully automated his job from his company because he feared it would claim the IP as its own and refuse to compensate him. Another, who asked to be identified only as Jordan, told me he had once inadvertently automated an entire department into redundancy. He now saves “several weeks’” worth of time a year with automation scripts. Jordan says he and his colleagues keep a tight lid on their automation techniques, to maintain control over how they’re used: “We generally keep these tools to ourselves.”
Another programmer went to great lengths to conceal the contours of his fully automated $50,000 per year job from his boss. Management could check in on his computer screen via the network, so he ran a loop of prerecorded video to hide the fact that he wasn’t actually working. In his advice-seeking post, Etherable wrote, “It doesn’t feel like I’m doing the right thing.”
“I don’t understand why people would think it’s unethical,” Woodcock says. “You use various tools and forms of automation anyway; anyone who works with a computer is automating work.” He says if any of these coders had sat in front of the computer, manually inputting the data day after day, they’d never be reprimanded. But by demonstrating that they’re capable of higher levels of efficiency, some may, perversely, feel like they’re shirking a duty to the companies that employ them. This is perhaps why automating work can feel like cheating, and be treated as such by corporate policy. On Amazon Mechanical Turk, the tech company’s marketplace for microwork, automation is explicitly against its terms of service—and the gig workers like those on the platform, who labor for cents per task, could stand to benefit from automation most of all.
Some coders say that they’ve been fired outright for automating their work. In 2011, a user posting as AcceptableLosses wrote, “They took what I had developed, replaced me with an idiot that they showed how to work it, and promptly fired me for ‘insubordination.’ I had taken a business asset that was making them $30 grand a year profit and turned it into a million dollar a year program for the company, and they fired me for it to save ~30 grand a year on my salary. Job creators my ass.” As such, gainfully employed self-automators’ concerns are less likely rooted in ethical questions and more in not wanting to be fired or exploited by an employer that, as Woodcock notes, “expects not only all our time, but anything we create.” Wary self-automators, he speculates, “don’t trust our workplaces. The boss is going to say, ‘Thank you, good work. Now do it again.’”
***
Few workers may have the desire to fully self-automate, but it appears a growing number are interested in scripting the busy work. The productivity web is littered with blog posts and how-to articles with titles like “How I Automated My Job With Node JS,” and there are dozens of podcasts about every conceivable kind of automation: small business, marketing, smartphone. It’s a burgeoning cottage industry.
“I see it as a grassroots effort by office workers and others who use a computer as part of their job,” Al Sweigart, the author of Automate the Boring Stuff With Python, told me in an email. Even those with little or no familiarity with programming are now seeking out his work, driven by the ease of automating modern jobs. “I get emails from readers who tell me that they’ve freed up several hours of their (and their coworkers’) days with a collection of small programs,” Sweigart writes.
As it stands, self-automation can be empowering. But as automation techniques become better understood, they may simply become yet another skill set management can expect employees to possess, or learn—passing the gains to their organization, then making themselves useful in some other way. “Employees will increasingly need to automate their own jobs or get moved out,” writes the Harvard Business Review. “Worldwide, we’ll see many more top-down managerial mandates for bottom-up automation initiatives.” And the rich and their employee-built bots will again swallow the gains.
Before that happens, anyone who works with code may want to consider the benefits enjoyed by self-automation. They’re a sort of test case for how automation could deliver a higher quality of life to the average worker, albeit an imperfect one. “The problem is for automation to work, it needs to be democratized,” Woodcock told me. “It’s a step forward that it’s not a corporate manager who’s delivering automation. It’s still not a democratic process.” Self-automators are acting alone, deciding when and how to replace their own job with code. Ideally, automation decisions would happen collectively, with colleagues’ and peers’ input, so the gains could be evenly distributed.
In 1932, Bertrand Russell wrote that “a great deal of harm is being done in the modern world by the belief in the virtuousness of work, and that the road to happiness and prosperity lies in an organized diminution of work.” In 2018, that might mean self-automators’ reclaiming parts of their workday; tomorrow it could mean working to secure automated gains for the masses. “I worry quite a bit that there really isn’t enough work to go around for everyone to work full-time,” Todd Hilehoffer says. Gary, the early-’90s self-automator, asked me, “Why is earning money for stockholders more important than employee quality of life? The system shouldn’t be more important than the individuals who helped make that system relevant.”
Self-automators show that coders are in a unique position to negotiate with employers over which automation-derived gains—like shorter workweeks and greater flexibility to pursue work that interests them—should be kept by workers. There’s little evidence of any interest in doing so, but theoretically, self-automators could organize, and distribute automation techniques among middle- and working-class coders, giving rise to an industry that could actually enjoy that 15-hour workweek. It seems a rare opportunity—perhaps, with the advance of AI, one of the last—to try to set the terms for a mode of automation that puts people first.Brian Merchant is a writer and editor in Los Angeles. He’s the author of The One Device: The Secret History of the iPhone, and the forthcoming Blood in the Machine, a book about the Luddite uprisings and the impact of automation.
