Why SQL Still Deserves Deliberate Practice

SQL has a strange reputation among languages developers actually use. Nobody puts "spaced repetition practice" next to it the way they might for algorithms or a new framework. Most people learn just enough to get their first few queries working, then treat everything past that as "look it up when you need it."

That works, mostly, until it doesn't — a production incident at 2am, a data migration under time pressure, an interview screen-share where autocomplete isn't there to save you. That's usually the first time someone realizes JOIN, GROUP BY, and a correlated subquery were never actually fluent, just familiar-looking.

Familiar isn't the same as fluent

There's a real gap between recognizing a JOIN when you see one and being able to write the right one, from a blank query, under a real constraint. Most people who "know SQL" are actually pattern-matching against queries they've seen before — which works fine until the problem in front of them doesn't match a pattern they've memorized.

Why AI tools make this worse, not better

Autocomplete for SQL is unusually good, because SQL is unusually regular — table and column names practically write the query for you. That regularity is exactly what makes it easy to lean on a suggestion instead of actually reasoning through what a GROUP BY is doing, or why a LEFT JOIN returns NULLs where an INNER JOIN would've silently dropped rows. The skill erodes quietly because the queries still work.

What's actually worth being fluent in

• Aggregation and grouping. COUNT, SUM, AVG, GROUP BY, and HAVING come up in nearly every real query that isn't a toy example, and HAVING vs. WHERE is a genuinely common point of confusion worth clearing up once and for all.
• JOINs, including when they don't match. Being able to predict what a LEFT JOIN returns when there's no match, without running it first, is the difference between debugging a data problem in seconds versus staring at unexpected NULLs for twenty minutes.
• Subqueries, correlated and otherwise. The moment a subquery needs to reference a column from the outer query, a lot of "I know SQL" confidence quietly evaporates.
• Window functions. Ranking, running totals, and "compare this row to the rest of its group" are extremely common asks in real data work, and they're the first thing most self-taught SQL knowledge skips entirely.

Practicing SQL the same way you'd practice anything else

The fix isn't reading another article about JOIN syntax — it's writing queries from a blank editor against a real problem, getting told exactly why a query is wrong when it is, and doing that enough times that the reasoning stops being effortful. The same deliberate-practice approach that works for rebuilding rusty JavaScript or Python works just as well here.

That kind of practice — writing a real query, finding out immediately why it's wrong, and doing it again — is exactly what SoloScript's SQL track is built around: SELECT through window functions and CTEs, graded by actually running your query against a real database instead of matching it against expected text.