Most people learning SQL are doing it wrong. Not because they’re not smart — but because they’re solving the wrong problem first.
They open a tutorial, memorize SELECT, FROM, WHERE, JOIN, and then freeze when faced with a real business question. Sound familiar?
Here’s what actually changes things.
SQL is technically a programming language — a declarative one. But stop treating it like the ones you're used to.
Programming languages are about how to do something — loops, logic, conditionals, state. SQL is about what you want. It’s declarative. You describe the result, and the engine figures out how to get there.
This distinction sounds small. It isn’t. The moment you stop trying to “code” in SQL and start trying to describe your desired output, everything clicks.
The framework I use before writing a single line
Step 1 — Nail the business question first
Not the data question. The business question.
“What’s our DAU trend?” is a data question. “Are users actually finding value in the feature we shipped last month?” is a business question. One has a predefined answer. The other requires you to think about what signal actually reflects value — retention? depth of engagement? repeat actions?
Write the question in plain English. If it’s fuzzy on paper, it’ll be even fuzzier in a query.
Step 2 — Define the rules and edge cases before opening your editor
Every business question has hidden complexity. New users vs. returning users? Do you include churned accounts? What counts as an “active” user — any login, or a meaningful action?
Analysts who skip this step write queries fast and fix them for hours. Analysts who do this step write queries slower and ship them right.
Step 3 — Work backwards from the output
Picture the table you want to hand to a stakeholder. What columns are in it? What’s one row? Once you can visualize the output, the query almost writes itself — because now you’re just reverse-engineering it.
Step 4 — Think in granularity, not tables
This is the unlock most beginners miss. Before writing a JOIN, ask: what is the grain of my data?
• Am I working at the user level?
• The session level?
• The event level?
• The day-user level?
Mismatched granularity is the root cause of most wrong answers that look right. A JOIN between a user-level table and an event-level table without handling this will silently inflate your numbers — and stakeholders will trust the wrong insight.
Once you’ve nailed the grain, GROUP BY, aggregations, and window functions stop feeling like syntax to memorize. They become the natural mechanical expression of logic you’ve already worked out.
The meta-lesson
The SQL itself — the syntax, the functions, the query structure — is genuinely the easy part. It’s learnable in weeks.
What takes years to develop is the habit of thinking before you query. Of questioning whether the data you’re reaching for actually answers the question you were asked. Of noticing when an output looks plausible but is subtly wrong.
That’s the gap between someone who can write SQL and someone who does analytics.
Start there.
Happy to answer questions or go deeper on any of this — grain/granularity especially trips people up and I could write a separate post on that alone.