Workers who automated their jobs: telling bosses, owning the code
Two real cases, the 10 top answers to the most-read question on it, and the copyright rules of five jurisdictions on who owns a script written for the job.
The short read
A worker's program did a month of data entry in 10 minutes; their question about telling has 554,870 views.
- Six of the 10 top-voted answers said tell, none defended the fake bugs, and the worker who did tell was promoted twice in 14 months.
- In the US, UK, EU, Sweden and Germany, a program written as part of the job belongs to the employer unless a contract says otherwise.
What you can do with this
If you have automated part of your job, read your contract's ownership clause, stop any pretense of manual work, and bring your boss the tool with a list of what you could take on next.
In this article
- The hidden version: a month of work in 10 minutes
- What 10 top answers advised: mostly tell, never fake bugs
- The told version: two promotions in 14 months
- Who owns the script: the law answers what the forum guessed
- In the US, the test asks whether it was the usual work
- The trade-off: what telling costs and what hiding costs
- What this means for you
- How we made this
In June 2017, a programmer posted a question on Workplace Stack Exchange that had been viewed 554,870 times by October 22, 2026. A program they wrote did in about 10 minutes what “used to take the last guy like a month.”
They worked 1 to 2 hours a week for a full-time wage and had told no one for 6 months. They even inserted “a few bugs here and there to make it look like it’s been generated by a human.”
Anyone who automates a chunk of their own work faces the same two questions: what to tell the boss, and whose the script is. The forum’s answers split on the first, and its most-voted claims on the second run against the law. So we read the 10 highest-voted answers and set them beside a second worker who told their boss and posted what followed over five years.
Then we read the copyright law of five jurisdictions on who owns code an employee writes. It is a reading of public texts, not legal advice.
The hidden version: a month of work in 10 minutes
The first worker was hired as a programmer, but the job was “pretty much glorified data entry”: monthly spreadsheets turned into SQL scripts for an old system. Analysts spent “a fair bit of time verifying” the work because the manual process made mistakes easy.
In 18 months they had “figured out all the traps,” and for the last 6 a program they wrote had done the work. Their fear was plain: “If I tell them, they will probably just take the program and get rid of me.” So once a week they reported progress on work already done and let the analysts test output with planted errors.
The question’s text says nothing about how it ended, so we do not know. What we do have is what 29 people answered.
What 10 top answers advised: mostly tell, never fake bugs
The question has 29 answers. On October 22, 2026, we pulled them through the Stack Exchange API and read the 10 with the most votes in full (33 to 687 votes each). The codes below are our reading of each answer, not the authors’ labels.
Guess first what the top-voted answer said. It said there is no duty to tell.
| Answer (votes) | Advice, our reading | Calls the fake bugs wrong |
|---|---|---|
| 687 | No duty to tell, but “you can’t lie about it” | Yes |
| 392 | Tell, and see if they agree | Yes |
| 333 | Tell, framed as a side project | Not raised |
| 215 | Tell; you may get more work to automate | Yes |
| 194 | Tell; not telling is “the worst choice” | Not raised |
| 110 | Keep quiet, phase the bugs out slowly | Yes |
| 108 | Keep going, or sell them the script | Not raised |
| 63 | Tell “immediately” | Yes |
| 63 | See an employment lawyer, renegotiate or sell | Not raised |
| 33 | Tell, or find a new job first, then tell | Yes |
Six of the 10 said tell, and those six hold 1,230 of the 2,198 votes. Six said the planted bugs were wrong, and none of the 10 defended them.
The top answer drew the line where five others did too. “You sell results,” it argued, so automating is fine. But “producing sub-par results to conceal the amount of time you actually work is unethical.”
We agree with that line. The automation was never the problem. The planted errors were, because analysts spent paid time checking mistakes made on purpose, and their checks were a cost the employer could see.
The told version: two promotions in 14 months
A second worker, at a company of about 15 people, asked the opposite question in October 2016 (46,807 views). They had automated 80% of their job and wanted to raise it before the project ended. They told their boss 3 months ahead. The boss answered: “I’m pretty certain we can find other projects for you.”
The worker added updates to the question for five years, the last edit in August 2021. At one year, the automation “did, indeed, turn out to need a lot of ongoing development, extension and maintenance.” When a senior colleague left, the worker was given the operational half of that job “to take over, learn, and automate in similar fashion.”
At 14 months they had been promoted twice and had a junior employee. At five years the company had been sold to a multinational, and the worker left to consult, writing that “they bought me out.”
One case proves nothing about odds, and the worker says “lots of serendipity” was involved. But it shows a mechanism the hidden version cannot reach. A script that keeps running needs someone to maintain it, and an employer that knows about the script knows who that is. Our xkcd table with upkeep counted makes the same point in hours.
Who owns the script: the law answers what the forum guessed
At least six of the 29 answers made a claim about who owns the program, and they disagreed. The two most-voted of those said the worker might keep it. One (108 votes) said it “doesn’t really belong to the company” because it was made on the worker’s own time. Another (63 votes) said a firm that is not IT-focused “probably” has no ownership clause, “so you may be able to sell it back to them.”
The law texts below start from the other side. In all five, the employer gets the rights by default when the program is written for the job, with no clause needed; only a contract can change that. We read them on October 22, 2026.
| Jurisdiction | Text | Who owns a program written for the job | Can a contract change it |
|---|---|---|---|
| United States | 17 U.S.C. § 101 and § 201(b) | A “work prepared by an employee within the scope of his or her employment” is a work made for hire; the employer “is considered the author” | Only by a “written instrument signed by them” |
| United Kingdom | CDPA 1988, s. 11(2) | A literary work “made by an employee in the course of his employment”: the employer is “first owner”; programs are literary works under s. 3(1) | “Subject to any agreement to the contrary” |
| European Union | Directive 2009/24/EC, art. 2(3) | Created “in the execution of his duties or following the instructions given by his employer”: the employer “exclusively” holds “all economic rights” | “Unless otherwise provided by contract” |
| Sweden | Upphovsrättslagen 40 a § | Created “as part of” the employee’s duties or on the employer’s instructions: copyright passes to the employer (our translation) | “Unless something else has been agreed” (our translation) |
| Germany | UrhG § 69b (English translation) | Created “in the execution of his or her duties”: “the employer alone is entitled to exercise all economic rights” | “Unless otherwise agreed” |
In the US, the test asks whether it was the usual work
The US test needs one more step, because the Copyright Act does not define “scope of employment.” The Copyright Office’s Circular 30 (revised August 2024) points to the Supreme Court’s 1989 ruling in Community for Creative Non-Violence v. Reid and lists questions to ask. Among them: was the work “created pursuant to the creator’s usual tasks,” during “authorized work time,” and with the hiring party’s tools?
For the first worker, the strongest fact is the first one. The program did their usual tasks, every month, on the employer’s data. “My own time” is a weak argument for a tool whose whole job is the work you are paid for. We cannot say how a court would weigh a script written partly at home, and the factors exist because cases differ.
Two limits on the table. It covers copyright in the code only; confidentiality clauses and trade secret rules are separate, and we did not read them. Under the EU directive’s article 1(2), “ideas and principles” behind a program “are not protected by copyright.” The know-how behind a script is a separate question from the code.
The trade-off: what telling costs and what hiding costs
Telling has a real risk, and the forum did not wave it away. The 33-vote answer advised finding another job first if the notice period is short. The first worker’s fear, that the employer “will probably just take the program,” is not irrational where there is little other work. Under all five laws above, a program written for the job would most likely be the employer’s anyway.
Hiding costs more over time. Planted errors create work for colleagues and a record of deception if anyone looks closely. A script nobody else knows about fails with nobody to fix it, and you cannot put it on a resume without explaining why your employer never heard of it. If you are recording what colleagues do to find more work to automate, read our piece on employee monitoring and GDPR first.
What this means for you
If you have automated part of your job, the decision is when and how to tell, not whether the code is yours to sell. Do it in this order:
- Read your contract’s IP clause. Look for words like “intellectual property,” “inventions” or “works created in the course of employment.” Where it says nothing, the default rules in the table above apply.
- Stop any pretense now. Deliver results when they are ready and drop planted errors. That ends the part six of the 10 top answers called wrong and none defended, before the conversation starts.
- Write down what the tool does and what still needs you: the inputs it expects, how it fails, the checks you run. The second worker’s script needed “ongoing development, extension and maintenance,” and so will yours.
- Bring a proposal, not a confession. Show the time saved, ask what to take on next, and list two or three other manual jobs you could automate. Our noticing what to automate piece has a one-week tally for finding them, and the automation payback formula turns the time saved into a number a manager can read.
- Ask for terms in writing if you want to keep rights to the tool or work by results instead of hours. Every law above lets a contract change the default; none lets a forum answer do it.
The second worker raised it 3 months before the work ran out. Five years later the company “bought me out,” in their words, and they left to consult for other firms in their industry.
How we made this
On October 22, 2026, we fetched both Workplace Stack Exchange questions and all 29 answers to the first through the Stack Exchange API 2.3. We read the 10 highest-voted answers in full and coded each one’s advice by hand; the codes are our reading. The same day we read the copyright texts in the table on official sites (the German law in its English translation), plus Circular 30 and the Reid decision. We did not contact either worker, could not check what they wrote, did not read case law beyond Reid, and did not read confidentiality or trade secret law.
Sources
- Workplace Stack Exchange: Is it unethical for me to not tell my employer I’ve automated my job? (June 27, 2017) and I’m about to automate myself out of a job (October 3, 2016, last edited August 20, 2021); Stack Exchange API 2.3, answers on questions
- United States: 17 U.S.C. § 101, 17 U.S.C. § 201, Copyright Office Circular 30, Works Made for Hire, Community for Creative Non-Violence v. Reid, 490 U.S. 730 (1989)
- United Kingdom: Copyright, Designs and Patents Act 1988, s. 3 and s. 11
- European Union: Directive 2009/24/EC on the legal protection of computer programs
- Sweden: Lag (1960:729) om upphovsrätt till litterära och konstnärliga verk, 40 a §
- Germany: Copyright Act (UrhG), English translation, § 69b
