How much does zuzu.codes cost?

The starter track is free — read all lessons and practice for free. Full access to every track (current and future) is $14.99/month. Cancel anytime.

How long does each track take?

Each track is designed as a 30-day challenge — one lesson per day, about 15 minutes each. Go at your own pace, but the structure is built around daily consistency.

What's the lesson format?

Each lesson is a student-teacher dialogue with code examples, followed by a hands-on code challenge in an in-browser editor. You read, you understand, then you write real code.

Do I need prior coding experience?

Our beginner track starts from absolute zero — no prior experience needed. Advanced tracks build on earlier ones, and the platform tells you exactly where to start.

How is zuzu.codes different from freeCodeCamp or Codecademy?

zuzu.codes uses a structured 30-day track format with dialogue-based teaching, an in-browser code editor, and gamification (XP, streaks, progress tracking). The format builds genuine understanding through daily practice.

Data shape mapping — Automation Patterns

Day 3 · ~12 min●

Tool A returns this:

python

[{"id": 1, "name": "alpha"}, {"id": 2, "name": "beta"}, {"id": 3, "name": "gamma"}]

Tool B's create call wants this:

python

{"items": ["alpha", "beta", "gamma"], "count": 3}

The data is the same. The shape is different. Step 2 of the chain is the reshape.

python

rows = [{"id": 1, "name": "alpha"}, {"id": 2, "name": "beta"}, {"id": 3, "name": "gamma"}]
names = [r["name"] for r in rows]
payload = {"items": names, "count": len(names)}

List comprehension to extract one field, then build the target dict.

Pure Python — no APIs at all in the middle?

Right. The reshape is just code you'd write in Python Foundations — comprehensions, dict-building, len(). The skill is recognizing that step 2 is the reshape, not another API call. New programmers reach for an API when they should reach for [r['name'] for r in rows].

Why is this a separate lesson?

Because the reflex "what shape does B want, and how do I get there from A's shape" is the most common reason chains break. Yesterday's chain was simple — extract one field. Real chains reshape lists into dicts, dicts into lists, group, filter, project, rename. Today is just the simplest of those transforms — but the pattern.

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

Different tools were designed by different teams over different decades. Their input/output shapes don't agree:

Gmail returns messages as [{id, subject, from, body}, ...]
Sheets append wants [[col1, col2, col3], [col1, col2, col3]] (list of lists)
Calendar create wants {summary, start_datetime, ...} (a single dict per call)
Tasks create wants {tasklist_id, title} (one at a time)

The reshape is unavoidable. The good news: it's pure Python.

The four common reshapes

1. Extract a field (list → list)

python

names = [r["name"] for r in rows]
# ["alpha", "beta", "gamma"]

2. Project to a smaller shape (list of dicts → list of dicts)

python

projection = [{"name": r["name"], "id": r["id"]} for r in rows]

3. List of dicts → list of lists (for Sheets append)

python

rows_for_sheet = [[r["id"], r["name"]] for r in rows]

4. Aggregate (list → single dict)

python

payload = {"items": [r["name"] for r in rows], "count": len(rows)}

Defensive reshapes — `.get` on every field

Real API responses sometimes drop fields. Reshape defensively:

python

names = [r.get("name", "(unnamed)") for r in rows]

One missing name field crashes the comprehension if you wrote r["name"]. With .get(...), the script keeps working.

When the reshape is the heavy logic

Don't be surprised if step 2 of a chain is 10 lines of Python and step 1 + step 3 are 2 lines each. The reshape is where business logic actually lives — "only items with status=active", "group by category", "normalize the date format". The tool calls are just I/O.

Build the target shape, then assert it

A quick assertion catches reshape bugs before they hit the API:

python

payload = {"items": names, "count": len(names)}
assert isinstance(payload["items"], list)
assert isinstance(payload["count"], int)

Fails locally with a clear message instead of producing a confusing 400 from the next API.

Day 3 · ~12 min●

Tool A returns this:

python

[{"id": 1, "name": "alpha"}, {"id": 2, "name": "beta"}, {"id": 3, "name": "gamma"}]

Tool B's create call wants this:

python

{"items": ["alpha", "beta", "gamma"], "count": 3}

The data is the same. The shape is different. Step 2 of the chain is the reshape.

python

rows = [{"id": 1, "name": "alpha"}, {"id": 2, "name": "beta"}, {"id": 3, "name": "gamma"}]
names = [r["name"] for r in rows]
payload = {"items": names, "count": len(names)}

List comprehension to extract one field, then build the target dict.

Pure Python — no APIs at all in the middle?

Why is this a separate lesson?

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

Different tools were designed by different teams over different decades. Their input/output shapes don't agree:

Gmail returns messages as [{id, subject, from, body}, ...]
Sheets append wants [[col1, col2, col3], [col1, col2, col3]] (list of lists)
Calendar create wants {summary, start_datetime, ...} (a single dict per call)
Tasks create wants {tasklist_id, title} (one at a time)

The reshape is unavoidable. The good news: it's pure Python.

The four common reshapes

1. Extract a field (list → list)

python

names = [r["name"] for r in rows]
# ["alpha", "beta", "gamma"]

2. Project to a smaller shape (list of dicts → list of dicts)

python

projection = [{"name": r["name"], "id": r["id"]} for r in rows]

3. List of dicts → list of lists (for Sheets append)

python

rows_for_sheet = [[r["id"], r["name"]] for r in rows]

4. Aggregate (list → single dict)

python

payload = {"items": [r["name"] for r in rows], "count": len(rows)}

Defensive reshapes — `.get` on every field

Real API responses sometimes drop fields. Reshape defensively:

python

names = [r.get("name", "(unnamed)") for r in rows]

One missing name field crashes the comprehension if you wrote r["name"]. With .get(...), the script keeps working.

When the reshape is the heavy logic

Build the target shape, then assert it

A quick assertion catches reshape bugs before they hit the API:

python

payload = {"items": names, "count": len(names)}
assert isinstance(payload["items"], list)
assert isinstance(payload["count"], int)

Fails locally with a clear message instead of producing a confusing 400 from the next API.

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — `.get` on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — `.get` on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — `.get` on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Sign up to practice

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — `.get` on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Sign up to practice

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — .get on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — .get on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — .get on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Sign up to practice

Data shape mapping — the reshape between tools

Why the shape mismatch is the rule, not the exception

The four common reshapes

Defensive reshapes — .get on every field

When the reshape is the heavy logic

Build the target shape, then assert it

Sign up to practice

Defensive reshapes — `.get` on every field

Defensive reshapes — `.get` on every field

Defensive reshapes — `.get` on every field

Defensive reshapes — `.get` on every field