The Tyranny of Repetition: Why Automation Became My Obsession

The Tyranny of Repetition: Why Automation Became My Obsession

The coffee is still too hot to drink when the first notification arrives. It's 8:47 AM on a Monday, and already my inbox has accumulated seventeen new messages since I left the office on Friday evening. By 9:15, I will have sixty-three. But the number itself isn't the problem—it's what each of those emails demands of me that slowly erodes the morning, then the afternoon, then the week.

I am a data analyst for a mid-sized manufacturing company. My job, officially, is to find patterns in data that help executives make better decisions. Unofficially, I spend an unseemly portion of my time copying information from one spreadsheet to another, renaming files according to conventions that vary by department, and drafting the same paragraph of contextual explanation that executives seem to require before they can act on the very insights I generate for them.

That Monday morning, I sat down with the same ritual I perform every weekday: open my laptop, stare briefly at the calendar's collision of meetings, and begin the triage. Email triage is its own kind of work—sorting the urgent from the important, the actionable from the informational, the genuinely time-sensitive from the merely anxious. By the time I finished my initial pass, it was 10:30. In those ninety minutes, I had responded to fourteen emails, flagged nine for later action, and moved three to a folder I optimistically label "reference" knowing full well I will never open it again.

The quarterly report was waiting for me.

To generate this report—something the CFO expects to see in her inbox by Wednesday noon—I needed data from twelve different Excel files. Each file represented a different department: operations, sales, human resources, supply chain, customer service. Each file had been maintained by a different person, using different naming conventions, different column headers, and different assumptions about data hygiene. One file used dates in MM/DD/YYYY format; another used DD/MM/YYYY; a third used a proprietary date encoding that appeared to be calculated as "days since we started this system, or maybe something else entirely."

My job, in that moment, was not analysis. My job was translation. I would spend the next four hours opening each file, understanding its structure, copying the relevant columns into a master spreadsheet, reconciling inconsistencies, and building formulas that would—hopefully—produce the numbers my colleagues expected to see. Four hours of work that a well-designed system could accomplish in minutes.

But I didn't have a well-designed system. I had a job.

And so I copied, and I pasted, and I fixed the formatting, and I wrote the explanatory paragraphs, and I checked my email between each major step because what else was there to do while Excel recalculated? The report landed in the CFO's inbox at 3:47 PM on Tuesday, approximately twenty-eight hours after I had begun the work. She replied with three questions and a request for two additional charts. I completed those changes by 5:30 that evening, sent them over, and considered the project done.

The next morning, I arrived to find an email from my manager. "Great job on the Q3 report!" it began. I felt a brief flush of professional satisfaction. Then I read the next sentence: "We need to do this for Q4, so please start thinking about how to make the process more efficient."

Make the process more efficient.

As if I hadn't spent three years trying to do exactly that. As if efficiency were a destination I had simply failed to reach through insufficient effort. As if the problem were not the process itself but my inability to execute it more quickly.

That email sat in my inbox for two days before I responded. I wrote something diplomatic about "exploring automation options" and "identifying bottlenecks." What I actually did was sit at my desk, stare at the wall, and wonder why it felt so impossible to simply build the tools I needed to do my job well.

This book exists because of that Monday. Because of those four hours of copying and pasting. Because of the frustration that accumulated over years of similar mornings, similar reports, similar small indignities of knowledge work that demanded repetitive effort while offering minimal intellectual engagement. It exists because I eventually found a way out—not through corporate software solutions, not through hiring assistants, but through learning to code. Through discovering Python. Through the gradual, sometimes frustrating, ultimately transformative process of building my own automation systems.

But before I can tell you about the solution, I need to help you understand the problem more clearly. Because most of us experience repetitive work the way we experience slow leaks—we know something is wrong, but we adapt to the drip long before we think to call a plumber. The inefficiency becomes invisible through familiarity. The cognitive cost accumulates without ever registering as a distinct problem.

In this chapter, we'll explore the hidden architecture of repetitive work: why it feels so draining even when it doesn't feel difficult, why we tend to accept it as inevitable, and why the first step toward automation isn't learning to code—it's learning to see.

---

The Cost Iceberg: What We See Versus What We Pay

When I talk to colleagues about the time they spend on repetitive tasks, they often estimate based on what they can observe directly. "Maybe an hour a day on emails," they say. "Two hours on data entry." "Half an hour renaming files." These estimates are reasonable, as far as they go. But they capture only the visible portion of the cost—the tip of what I call the *cost iceberg*.

Consider the quarterly report I described. The visible cost was four hours of active work: the time I spent opening files, copying data, and building the final document. But the invisible costs began accumulating long before I sat down at my desk, and they continued long after I hit "send."

Before I even began the technical work, I spent time mentally preparing. I reviewed what the CFO had asked for in previous quarters. I thought about which departments had given me trouble last time. I anticipated the questions she would ask and prepared my answers in advance. This cognitive preamble—the mental work of context-setting—consumed perhaps thirty minutes of attention that never appears in any timesheet.

During the work itself, the visible task (copying and pasting) was interleaved with invisible overhead. Every time I switched between files, my working memory had to reload the context: where was I in this document, what did these column headers mean, what was the naming convention I was supposed to follow? This reloading is called *context-switching cost*, and it represents a significant portion of the hidden tax on repetitive work.

After the report was sent, the invisible costs continued. I worried about whether I had caught all the errors. I mentally rehearsed the questions the CFO might ask. I made a note to follow up on Wednesday to ensure everything was satisfactory. This *attention residue*—the cognitive fragments that linger after a task is nominally complete—keeps us from fully engaging with whatever comes next.

Research by Sophie Leroy, a professor at the University of Washington, has documented this phenomenon systematically. In a series of studies, Leroy found that people who are still mentally engaged with a previous task perform significantly worse on new tasks, even when the previous task has been formally completed. This isn't about willpower or discipline. It's about the architecture of human attention: we don't have an "off switch" for tasks we've been working on, and the cognitive resources we spend managing incomplete mental threads are resources unavailable for everything else.

```mermaid flowchart TD A["8:47 AM - Day Begins"] --> B["Email Triage: 90 minutes"] B --> C["Quarterly Repo