Cells, Functions, and the Joy of Making Things Behave

=SUM(A1:A10)
A small calculation many of us wrote long before we thought of ourselves as capable of programming a machine.

Perhaps you messed around with object-oriented languages trying to script something, or clicked "View Source" to see some new Javascript revelation on your favorite website. And that was how you got started. But for most of us, the gateway into programming was Excel. We just didn't know we were programming, which is either a testament to the brilliance of the spreadsheet's design or an indictment of how narrowly we define the word "programming," or possibly both, and the fact that it's both is probably the whole point.

I want to tell you about a woman named Diane. That's not her name. I'm admittedly remixing details because the last thing Diane wants is to be identified as someone who spent years building a financial model that, by the time I encountered it, had become something closer to a living organism than a file. Twenty-six tabs. Each one feeding the next in a chain of references so long that tracing a single number back to its origin required the kind of patience usually reserved for genealogists or people who enjoy doing their own taxes. The formula bar, when you clicked on certain cells, displayed expressions that scrolled horizontally for what felt like a full breath and a half. VLOOKUP nested inside IFS nested inside other, more obscure functions, with a concatenation in the middle that pulled from a named range Diane had created years prior and never renamed from "TEMP."

That workbook ran a department. Quarterly forecasts, headcount planning, budget reconciliation. When the company's actual planning software couldn't handle a particular edge case (and there was always an edge case, because reality is an edge case), someone would say, "Just put it in Diane's sheet." And Diane would open the file, scroll to a tab no one else dared touch, and type something that looked like an incantation. Then a number would appear in a cell somewhere, and people would make decisions based on it.

I inherited the file after Diane left. No documentation. No README. No comments, because spreadsheets don't really have comments in the way that code does, or rather they do, but nobody uses them, because the whole premise of a spreadsheet is that you can see the logic right there in front of you, living alongside its data like a neighbor you can always ask. Except when the logic spans twenty-six tabs and references cells by address in ways that make you realize Diane had memorized the grid the way a chess player memorizes board positions. D14 wasn't a cell to Diane. It was "fully loaded contractor cost, West region, excluding the anomaly from Q2 2019 when we briefly had that consultant in Boise."

I spent days mapping the dependencies. Not because anyone asked me to, but because I couldn't stop. The workbook had a logic to it, a worldview, even. Diane had opinions about how costs should cascade, about which assumptions deserved their own tab versus which ones could live as hardcoded values (she was sparing with hardcoded values, which I came to respect), about the right level of granularity for a forecast that would ultimately be rounded to the nearest thousand anyway. Those opinions were expressed entirely in formulas. They were arguments made in cell references. What struck me wasn't the complexity. Software architects build complex things all the time, and they'd probably look at Diane's workbook and see fragility, single points of failure, the absence of version control. What struck me was that Diane had never once, in eleven years, called what she did "programming." She called it "maintaining the model." The software engineers down the hall used words like "architecture" and "deployment" and "refactoring." Diane used words like "updating" and "fixing" and, when things got really bad, "rebuilding." The same activities, described in a vocabulary carefully chosen to signal: this is not that. What I do is not what they do.

And Diane herself would have resisted any attempt to reclassify her. I know because I tried once, casually, told her that her lookup chains were doing the same work as the engineering team's database queries. She gave me a look I've come to recognize in people who suspect they're being managed. "It's a spreadsheet," she said, like she was correcting a mispronunciation. The engineers, for their part, would have resisted from the other direction, though they'd have been polite about it. Which is almost worse.

I watched a version of this play out in a meeting once. An analyst named James (also not his name) had built a reconciliation system in Google Sheets. It processed tens of thousands of rows, cross-referenced three data sources, flagged discrepancies, and generated a summary report. When he presented it, he started by apologizing. "I know it's just a spreadsheet," he said, with that particular deflection that isn't really self-deprecation but a preemptive shield against judgment he could already feel forming in the room. A senior engineer, arms crossed, laptop open to something else, suggested the whole thing could be "automated properly." He said it gently, the way you'd suggest a better restaurant to someone who seemed happy where they were. James nodded. The spreadsheet was quietly deprecated. The Python replacement took four months to build, required a developer to maintain, and did approximately the same thing. But now it lived in a repository, had a deployment pipeline, and belonged to engineering. James wasn't invited to the architecture reviews for the tool that replaced his work.

I think about that meeting more than I should.

Spreadsheets are a programming language disguised as a calculator, and the disguise works so well that we forgot it's a disguise. They translate human intention into machine-executable logic. The gap between =VLOOKUP(B2,Table1,3,FALSE) and a SQL query is syntax, environment, and which department gets headcount for maintaining it.

What accounts for their ubiquity is the feedback loop. Type a formula and the result appears immediately. No compilation step, no deployment pipeline, no waiting for a build to finish while you get coffee. The result is just there, in the cell. If it's wrong, you see it instantly. If it's right, you move to the next cell. Every programmer who has ever waited six minutes for tests to run knows how remarkable that is.

And the logic lives next to its data. You want to know how a number was derived? Look left. Look up. Follow the chain of cell references like breadcrumbs. This transparency is both the spreadsheet's greatest strength and its most dangerous quality, because it creates the illusion that everything is visible and therefore understood. In practice, Diane's workbook was no more transparent than compiled code. It just looked like it should be.

For some of us, and I include myself here, the spreadsheet was the moment of first contact with a larger idea. The realization that you could make a machine do what you wanted. That complex problems could be broken into small, manageable pieces, each one occupying its own cell, each one doing a tiny amount of work that accumulated into something you couldn't have done alone. The progression, as I remember climbing it, looked something like this:

My own version started with a budget tracker that grew, through the usual combination of ambition and poor planning, into something I hesitate to call a system but can't honestly call a spreadsheet anymore either. It began as a way to see where my money was going. Then I wanted to categorize. Then I wanted to forecast. Then I wanted conditional formatting that would turn cells red when I'd exceeded a threshold, because I apparently needed my financial anxieties to be color-coded. Each addition felt small. Each one added a layer of logic. By the time I realized I'd been programming, I'd already been doing it for months.

That early confidence, the feeling that a blank grid and a problem were sufficient raw materials, carried further than I expected. A lot of careers have started this way, though we don't usually trace them back to the spreadsheet. We trace them to the CS degree, the bootcamp, the first pull request. The spreadsheet gets left out of the origin story because it doesn't fit the narrative of becoming technical. It's more like remembering you could already swim when someone finally let you near the deep end.

I've watched people who would never describe themselves as technical build things that would genuinely unsettle a systems engineer. Cash-flow models stretching across two dozen tabs that predicted quarterly performance within a margin the company's official software couldn't match. Reconciliation sheets where a single array formula processed what amounted to a small database. Named ranges deployed like variables in a distributed system, carrying meaning from one tab to another in ways that made sense only if you understood the business logic they encoded, which is to say: only if you understood the business, which the engineers often didn't, which is another thing nobody mentioned in that meeting with James.

Those spreadsheets were fragile in the way all early systems are: held together by convention, dependent on their creator's memory, one accidental deletion away from catastrophe. They were also critical in the way core systems inevitably become: load-bearing, irreplaceable, the thing that actually works while the "proper" solution is perpetually six months from completion.

A spreadsheet looks sterile. Just a grid, all right angles and empty potential. But once you live in it long enough, it starts to feel more like a garden. Rows that need pruning because someone added data in 2021 that no one has looked at since. Formulas that sprawl until they choke out the cells around them, referencing tabs that were renamed or deleted, throwing errors that propagate silently until someone notices the quarterly report has been wrong for two months. Dead references you trim back, hoping nothing else depended on them, knowing something probably did.

There was a column in Diane's old workbook labeled "TEMP." It was created who knows when. By the time I found it, "TEMP" was referenced by fourteen other cells across five tabs. It contained contractor rates that were no longer accurate but couldn't be deleted without breaking the cascade. So it stayed. "TEMP," permanent as concrete, doing work its creator never intended, in a system that had long outgrown the problem it was built to solve.

That's programming too. Maybe that's programming most of all.