Building a personal learning plan: SQL to Python to AI

You bought three courses, bookmarked forty videos, and still cannot answer a simple question in a hiring screen: “Walk me through how you would check last month’s revenue.” The problem is not motivation. It is that your learning looks like a browser history, not a plan. SQL week, then a shiny Python notebook, then an AI chatbot that writes both for you until you cannot debug either.

This post is a one-shot guide to building a personal learning plan that moves you from solid SQL into practical Python and then into AI tools without skipping the foundation. You will leave with a skill ladder, a weekly template, and a worked example for someone with about eight hours a week. No series membership required. Just a plan you can actually follow.

What you’ll learn

Why random courses fail even when you finish them
A clear skill ladder: SQL first, Python second, AI as a multiplier (not a substitute)
How to set goals as outputs (queries, scripts, checked AI drafts), not hours watched
A sample 12-week plan and a week-by-week grid you can copy
Common plan-killing habits and a 30-minute setup exercise for this Sunday

Why “I’ll just learn as I go” stalls

Learning as you go works when the work itself is sequenced. Many analyst jobs are not. One week you clean a CSV. The next week someone asks for a cohort chart. Then leadership wants “something with AI.” Your calendar is a random sample of industry fashion, not a curriculum.

Three failure modes show up again and again:

Tool hopping: you start SQL, see a viral Python reel, jump to pandas, then pivot to a no-code AI demo. None of the skills compound.
Passive consumption: you watch full courses without shipping queries or scripts. Confidence feels high until the blank editor appears.
AI as a crutch too early: the model writes a join you do not understand. When the number is wrong, you cannot audit it. For how to check AI-written SQL specifically, see our tutorial on how to check AI-written SQL.

A personal plan fixes the sequence. You decide what “good enough” looks like at each stage before you add the next tool. That is boring on paper and liberating in practice.

The skill ladder: SQL, then Python, then AI

Think of three layers, not three separate careers.

Layer 1: SQL as your thinking language

SQL is how you talk to warehouse data: filters, joins, aggregations, window functions, grain. If you cannot state “one row means…” and prove it with a query, Python will only make the mess faster. AI will only make the mess look polished.

Minimum competence for an analyst path (not an engineer path) looks like this:

SELECT, WHERE, GROUP BY, HAVING with correct grain
INNER and LEFT joins without accidental fan-out
CASE logic for business rules
Window functions for ranks, running totals, and period comparisons
CTEs that read like a story instead of nested subqueries nobody trusts

When you can rebuild a weekly KPI from raw-ish tables and explain every filter, you are ready to layer Python. For structured practice, use the SQL series on this site and the broader paths on Learn.

Layer 2: Python as your workshop

Python is not “better SQL.” It is the workshop next door: APIs, files, charts, tests, automation, and light modeling. Analysts who learn Python well use it for the parts SQL is awkward at, not for rewriting every warehouse query in pandas because a blog said so.

Minimum competence for a practical analyst plan:

Virtual environments and a simple project folder layout
pandas for tabular work you already understand in SQL terms
Reading CSV or Parquet, basic joins, groupbys, and sanity checks
A plotting library well enough to make one honest chart, not twenty chart types
Functions, small scripts, and a README so next-month-you can re-run the work

Pair this layer with the Python series when you want progressive practice. The point of the plan is not “finish Python.” It is “ship two end-to-end analyses where SQL feeds Python or Python feeds a clear decision.”

Layer 3: AI as a multiplier you can audit

AI tools (chat assistants, coding copilots, document Q&A) help when you already know what “correct” looks like. They hurt when you use them to skip fundamentals. Your plan should introduce AI only after you can:

Spot a wrong join or wrong grain in SQL
Read a short Python script without panic
State the business question before you paste anything into a model

Then practice a disciplined loop: ask the model for a draft, restate the logic in your own words, run checks, and only then ship. For concept grounding on models and generative tools, start with what LLMs and generative AI actually are and the Practical AI series.

Skill ladder: SQL foundations, spreadsheet hygiene, Python workshop skills, quality habits, then AI as a multiplier.

The diagram is a ladder, not a menu. You can peek at higher rungs for motivation. You should not live there until the lower rung has proof: projects, not certificates alone.

Write goals as proof, not vibes

Vague goals (“get better at SQL”) invite infinite scrolling. Proof goals invite practice. Use this template:

By date X, I can demonstrate Y with artifact Z, checked by rule R.

Examples:

By week 4, I can write a CTE pipeline that computes weekly active users and retention, saved as wau_retention.sql, with a one-page note on grain and edge cases.
By week 8, I can load that result into Python, chart it, and write a three-paragraph decision memo for a fictional product lead.
By week 12, I can use an AI assistant to draft a variant query, then catch at least two deliberate mistakes I inject into the prompt history.

Notice the artifacts. Screenshots of course progress are weak proof. Re-runnable files and short writeups are strong proof. Hiring managers and future-you both prefer the second kind.

Budget hours like a scarce resource

Most people overestimate weekend heroics and underestimate weekday fragments. Design for the schedule you already have.

Weekly hours	Realistic focus	What to cut
4 hours	One layer only (usually SQL) for 8-10 weeks	Side tools, multiple courses, AI deep dives
6-8 hours	Primary layer + light secondary (notes, tiny scripts)	Long video marathons; prefer docs + practice
10-12 hours	Two layers with clear split (e.g. 7 SQL / 4 Python)	Social comparison projects that expand forever
15+ hours	Faster ladder, still proof-based	Tool shopping disguised as learning

Split each study block into three parts: learn (short reading or one concept), do (query or script), reflect (five sentences on what broke). Reflection is not optional fluff. It is how you stop repeating the same join mistake for six months.

A sample 12-week path

This plan assumes roughly eight hours a week, some access to sample data (public datasets or a company sandbox), and zero expectation that you become a platform engineer.

Weeks 1-4: SQL proof

Week 1: filters, aggregations, grain checks on one table
Week 2: joins and fan-out diagnostics (row counts before and after)
Week 3: CASE rules and a documented KPI definition
Week 4: windows + CTEs; ship kpi_v1.sql + a one-page definition

Weeks 5-8: Python workshop

Week 5: environment, project folder, load the same KPI output as a file
Week 6: transforms you already understand from SQL; assert row counts
Week 7: one clear chart and a short memo
Week 8: refactor into functions; add a README with how to re-run

Weeks 9-12: AI with a leash

Week 9: use AI to draft SQL only after you write the question and expected grain by hand
Week 10: deliberate error hunting (wrong join keys, time zone traps)
Week 11: AI-assisted Python cleanup; you keep ownership of tests and README
Week 12: package one portfolio-ready story: question, method, checks, decision

If eight hours is too much, stretch each block to six weeks. Do not “speedrun” by deleting checks. Speed without checks is how you graduate into confidently wrong analyses.

Worked example: Maya’s eight-hour week

Maya is a support ops lead who wants an analytics role. She has Tuesday and Thursday evenings (90 minutes each) and Saturday morning (about five hours). She does not have a warehouse job yet, so she uses a public e-commerce sample dataset and a free SQL editor plus a local Python install.

Her north-star proof for 12 weeks: Publish a repo folder with (1) SQL that defines weekly revenue and repeat-purchase rate, (2) a Python notebook-turned-script that charts both, (3) a one-page memo a fictional merchandising lead could act on, (4) a short log of AI prompts she rejected and why.

A single week in the middle of SQL month might look like this:

Sample weekly learning grid with learn do reflect blocks for SQL practice

Here is the same week as a simple schedule table she can paste into a notes app:

Block	Time	Learn	Do	Reflect
Tue	90 min	Read one join pitfall note	Write join of orders + customers; compare row counts	What fan-out risk did I miss?
Thu	90 min	Skim window function examples	Add lag for prior-week revenue	Did the window partition match grain?
Sat AM	5 hr	15 min review of notes only	Ship CTE version + save `weekly_revenue_v2.sql`	Write five sentences for the definition doc

Maya’s mid-plan SQL proof for repeat purchase might start like this (toy schema; focus on structure):

WITH order_facts AS (
  SELECT
    o.order_id,
    o.customer_id,
    DATE_TRUNC('week', o.order_ts) AS order_week,
    o.order_amount
  FROM orders o
  WHERE o.status = 'completed'
),
customer_weeks AS (
  SELECT
    customer_id,
    order_week,
    SUM(order_amount) AS revenue,
    COUNT(*) AS orders
  FROM order_facts
  GROUP BY 1, 2
)
SELECT
  order_week,
  COUNT(DISTINCT customer_id) AS active_customers,
  SUM(revenue) AS weekly_revenue,
  SUM(CASE WHEN orders >= 2 THEN 1 ELSE 0 END) AS multi_order_customers
FROM customer_weeks
GROUP BY 1
ORDER BY 1;

Her reflection after first run: “I treated multi-order as same-week only. The merchandising question might mean 30-day repeat. I need a definition line before I chart this.” That sentence is more valuable than three more tutorials. Later, when she invites AI to rewrite the query, she already knows what wrong answers look like.

On Python weeks she freezes the SQL output to a file so learning pandas does not turn into “debug the warehouse and the notebook at once.” On AI weeks she keeps a rejection log:

# ai_rejection_log.md (excerpt)
- Prompt: "join customers to orders"
  Rejected: model used INNER JOIN; we need customers with zero orders for funnel.
- Prompt: "weekly revenue by region"
  Rejected: model filtered test orders after aggregation; fixed by moving filter earlier.

That log becomes interview gold and personal quality control. It also keeps AI in the “multiplier” lane.

Resources that fit the ladder (not a shopping list)

Pick one primary resource per layer and stop browsing. Examples that are free or low-friction:

SQL: official dialect docs for the engine you use (Postgres, BigQuery, Snowflake) plus AMS SQL series practice
Python: official tutorial + pandas user guide for the operations you already do in SQL
AI literacy: vendor-neutral overviews and AMS Practical AI; always pair with verification habits

If your work involves pipelines or metric definitions later, you can branch into the data pipelines and metrics series after the ladder, not instead of it.

Common mistakes

Collecting courses like trading cards: one unfinished path beats five “started” badges.
Skipping grain and definitions: fancy windows on a broken grain still produce wrong dashboards.
Learning Python only through notebook demos: if you never re-run from a clean environment, you did not learn packaging for real work.
Letting AI write unchecked SQL: you practice typing prompts instead of practicing analysis.
No public or private portfolio artifact: without a file and a writeup, your brain discards the skill after the next shiny topic.
Comparing your week 2 to someone’s year 5 LinkedIn: plans die from unfair baselines. Track your own proofs only.
All input, no output: if a week has zero saved queries or scripts, it was entertainment.

Practice: 30 minutes this week

Open a blank doc. Write four sections only:

Hours I truly have: a number for the next 12 weeks, not a fantasy number.
Layer I am on: SQL, Python, or AI-with-leash. Pick one primary.
Proof goal: one sentence with artifact names.
This week’s three blocks: learn / do / reflect with calendar times.

Then create a folder learning-plan/ with proofs/ and notes/. Save one tiny artifact today even if it is a 15-line query. The plan becomes real when the folder is not empty.

If you want structured modules after the plan exists, browse Learn and stick to the path you wrote down.

Quick recap

Random tutorials feel productive and rarely compound. A sequenced ladder does.
SQL first for thinking and warehouse truth. Python second for workshop power. AI third as an audited multiplier.
Goals need artifacts and check rules, not vibes.
Budget real hours. Split blocks into learn, do, reflect.
A 12-week sample path is a template, not a religion. Stretch it before you skip checks.
Rejection logs for AI drafts turn tools into training, not dependency.

Sources

PostgreSQL official documentation (SQL reference for a common teaching dialect): https://www.postgresql.org/docs/current/
Python Software Foundation, The Python Tutorial: https://docs.python.org/3/tutorial/
pandas documentation, user guide: https://pandas.pydata.org/docs/user_guide/index.html
Mode Analytics SQL Tutorial (free structured SQL practice many analysts use): https://mode.com/sql-tutorial/
Google, People + AI Guidebook (practical AI product and use considerations): https://pair.withgoogle.com/guidebook/
NIST AI Risk Management Framework (organizational risk framing for AI use): https://www.nist.gov/itl/ai-risk-management-framework