The spreadsheet was already software

How do you convince a financial controller who works in Excel all day that she's already writing software?

I was asked to look at a finance department's "systems." What I found was a shadow IT setup built entirely in spreadsheets. VLOOKUP chains across a stack of workbooks on a shared drive. Nested IF statements deep enough to need a degree in bracket matching. VBA macros acting as a fragile, unversioned set of microservices.

When I suggested moving that logic into a proper web app, the department lead said no straight away. "Oh no," she said. "I'm just an accountant. I could never write code."

The workbook on her screen had more branching logic than the authentication service I'd written that morning.

A vocabulary problem

A lot of programming vocabulary describes things she already did every day.

So I mapped what she already knew onto new syntax:

"That twenty-line nested IF? We call that conditional logic. You're already writing code. You're just doing it in a tool that fights you."

She was still skeptical, but less defensive.

We translated her daily work into engineering terms:

• =IF(A1>100, "High", "Low") is A1 > 100 ? "High" : "Low", a ternary.
• =XLOOKUP() is a database join, run very inefficiently.
• =SUM() is an array.reduce() waiting to happen.
• Data validation rules are schema validation.
• Conditional formatting is state-driven CSS.

Seen that way, programming looked less like a secret art and more like Excel without the grid.

We skipped "Hello World" and went straight for her biggest weekly headache: reconciling expense reports submitted in several currencies. We wired up a simple React form with a Node backend that called an exchange rate API.

It had no tests and no responsive styling, and architecturally it was a mess. But for someone watching an afternoon of manual work turn into one click, it was magic.

She already had the skills

The real win was showing her the engineering skills she already had. She split huge reconciliations into small, checkable steps, which is breaking problems down. Her chained macros were pipelines under another name. She understood extract, transform, load without the acronym, and her #N/A fallbacks were try/catch blocks.

Plenty of engineering ideas are old ones with newer names. SQL is a polite way to ask a very large spreadsheet a question.

Don't teach syntax first. Teach it last, as the final step in fixing a problem that actually hurts.

She didn't care about the event loop or the virtual DOM. She cared about staying sane at quarter-end. Once code became the way out of that pain, she taught herself the syntax.

Afterwards

Her team kept building small internal tools. They aren't elegant, but the spreadsheet empire started shrinking.

And she stopped saying "I'm just an accountant."