I did not come to SQL as a programmer. I came to it as a marketer who was tired of not being able to answer one question: “how do you actually know it worked?”

I grew up around a business — the kind of house where the day’s sales were dinner conversation. So when I started running campaigns during my internships, I wasn’t satisfied with “the post did well.” I wanted the number behind it. For a while, that meant spreadsheets. And spreadsheets, it turns out, have a ceiling.

The spreadsheet wall

The wall showed up quietly. A campaign export with 40,000 rows that made my laptop fan scream. A VLOOKUP chain so long I couldn’t remember what it was doing. Three files that all had “final” in the name. I was spending more time wrangling the data than reading it. That’s when I decided to properly learn SQL, and took the End-to-End MySQL: Schema to Subqueries course to force myself through the fundamentals.

SELECT felt like a cheat code

The first real query I wrote returned exactly what I asked for, instantly, from a table with more rows than Excel would have opened. It sounds small. It did not feel small.

first_query.sql
-- my first useful querySELECT platform, SUM(spend) AS total_spendFROM campaignsGROUP BY platformORDER BY total_spend DESC;

GROUP BY was the moment it clicked that SQL thinks the way a marketer asks questions: “show me spend, but per channel.” “show me conversions, but per week.” The word “per” is almost always a GROUP BY.

The JOIN that broke my brain (then fixed it)

JOINs were where I nearly gave up. My campaign data lived in one table, my cost data in another, and I could not for the life of me get them to line up without either duplicating rows or losing them. I stared at a wrong number for two hours.

What fixed it was stopping and drawing it on paper — two boxes, a line between the matching keys. Once I could see that a JOIN is just “match these rows to those rows on a shared key,” it stopped being magic and started being a tool.

join_it.sql
-- spend and revenue, finally in one placeSELECT c.campaign, c.spend, r.revenue, ROUND(r.revenue / NULLIF(c.spend,0), 2) AS roasFROM campaigns cJOIN results r ON r.campaign_id = c.id;

Subqueries, and the level-up

Subqueries were the point where I felt like I’d actually crossed over. Being able to ask “which campaigns performed above the account average?” in one query — a question inside a question — changed how I thought about the data entirely.

You don’t need a computer-science degree to learn SQL. You need one real question you actually care about, and the stubbornness to not close the tab until you’ve answered it.

What it changed

SQL didn’t just make me faster. It changed the kind of conversations I could have. I stopped saying “I think it worked” and started saying “here’s the number, and here’s the query that got it.” That’s the whole reason the dashboards on this site exist — every one of them starts as a question written in SQL.

Next I wanted to go further than querying — I wanted to shape the data. That’s the story of how I learned Python.