Skip to main content

The Coders Programming Themselves Out of a Job

n 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. (It’s now 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 rising 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.

Comments

Popular posts from this blog

OWASP Top 10 Threats and Mitigations Exam - Single Select

Last updated 4 Aug 11 Course Title: OWASP Top 10 Threats and Mitigation Exam Questions - Single Select 1) Which of the following consequences is most likely to occur due to an injection attack? Spoofing Cross-site request forgery Denial of service   Correct Insecure direct object references 2) Your application is created using a language that does not support a clear distinction between code and data. Which vulnerability is most likely to occur in your application? Injection   Correct Insecure direct object references Failure to restrict URL access Insufficient transport layer protection 3) Which of the following scenarios is most likely to cause an injection attack? Unvalidated input is embedded in an instruction stream.   Correct Unvalidated input can be distinguished from valid instructions. A Web application does not validate a client’s access to a resource. A Web action performs an operation on behalf of the user without checking a shared sec

CKA Simulator Kubernetes 1.22

  https://killer.sh Pre Setup Once you've gained access to your terminal it might be wise to spend ~1 minute to setup your environment. You could set these: alias k = kubectl                         # will already be pre-configured export do = "--dry-run=client -o yaml"     # k get pod x $do export now = "--force --grace-period 0"   # k delete pod x $now Vim To make vim use 2 spaces for a tab edit ~/.vimrc to contain: set tabstop=2 set expandtab set shiftwidth=2 More setup suggestions are in the tips section .     Question 1 | Contexts Task weight: 1%   You have access to multiple clusters from your main terminal through kubectl contexts. Write all those context names into /opt/course/1/contexts . Next write a command to display the current context into /opt/course/1/context_default_kubectl.sh , the command should use kubectl . Finally write a second command doing the same thing into /opt/course/1/context_default_no_kubectl.sh , but without the use of k

标 题: 关于Daniel Guo 律师

发信人: q123452017 (水天一色), 信区: I140 标  题: 关于Daniel Guo 律师 关键字: Daniel Guo 发信站: BBS 未名空间站 (Thu Apr 26 02:11:35 2018, 美东) 这些是lz根据亲身经历在 Immigration版上发的帖以及一些关于Daniel Guo 律师的回 帖,希望大家不要被一些马甲帖广告帖所骗,慎重考虑选择律师。 WG 和Guo两家律师对比 1. fully refund的合约上的区别 wegreened家是case不过只要第二次没有file就可以fully refund。郭家是要两次case 没过才给refund,而且只要第二次pl draft好律师就可以不退任何律师费。 2. 回信速度 wegreened家一般24小时内回信。郭律师是在可以快速回复的时候才回复很快,对于需 要时间回复或者是不愿意给出确切答复的时候就回复的比较慢。 比如:lz问过郭律师他们律所在nsc区域最近eb1a的通过率,大家也知道nsc现在杀手如 云,但是郭律师过了两天只回复说让秘书update最近的case然后去网页上查,但是上面 并没有写明tsc还是nsc。 lz还问过郭律师关于准备ps (他要求的文件)的一些问题,模版上有的东西不是很清 楚,但是他一般就是把模版上的东西再copy一遍发过来。 3. 材料区别 (推荐信) 因为我只收到郭律师写的推荐信,所以可以比下两家推荐信 wegreened家推荐信写的比较长,而且每封推荐信会用不同的语气和风格,会包含lz写 的research summary里面的某个方面 郭家四封推荐信都是一个格式,一种语气,连地址,信的称呼都是一样的,怎么看四封 推荐信都是同一个人写出来的。套路基本都是第一段目的,第二段介绍推荐人,第三段 某篇或几篇文章的abstract,最后结论 4. 前期材料准备 wegreened家要按照他们的模版准备一个十几页的research summary。 郭律师在签约之前说的是只需要准备五页左右的summary,但是在lz签完约收到推荐信 ,郭律师又发来一个很长的ps要lz自己填,而且和pl的格式基本差不多。 总结下来,申请自己上心最重要。但是如果选律师,lz更倾向于wegreened,