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.

Errors in chains — Automation Foundations

Day 19 · ~11 min●

Two-step chain. Step 1 succeeds (you got the data). Step 2 fails (network blip). Without protection, the script crashes mid-chain — you lose the wasted read AND don't get a clear signal which step broke.

python

try:
    result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
    messages = result.get("messages", [])
except Exception as e:
    print(f"step 1 (read) failed: {type(e).__name__}")
    raise

try:
    toolset.execute_action(Action.GOOGLECALENDAR_UPDATE_EVENT, {"calendar_id": "primary", "event_id": "missing", "summary": str(messages), "start_datetime": "2026-12-31T10:00:00+00:00", "event_duration_minutes": 30})
except Exception as e:
    print(f"step 2 (write) failed: {type(e).__name__}")
    raise

Each step in its own try/except?

That's the granular pattern — pinpoints the exact failure. The trade-off is verbosity. For 2-step chains it's worth it. For 10-step chains you'd refactor into a helper function or a list of (step_name, action) tuples.

And raise inside the except — re-raises the same error?

Yes. After printing the diagnostic, raise lets the original exception propagate so the script still crashes. Without raise, you'd silently continue to the next step on a partially-broken state — usually worse than failing loudly.

Errors in chains — the per-step `try/except`

The pattern:

python

try:
    # step 1
except Exception as e:
    print(f"step 1 failed: {type(e).__name__}")
    raise

try:
    # step 2
except Exception as e:
    print(f"step 2 failed: {type(e).__name__}")
    raise

The diagnostic print + raise combo gives you:

a named failure point in the logs
the original traceback for full context
the script still ends on error (no partial-state continuation)

Why `raise` matters

Without raise, the except swallows the error and the script keeps running. If step 1 actually failed, step 2 would proceed with incomplete data — worse than crashing immediately.

python

try:
    messages = step_1()
except Exception:
    print("step 1 failed")
    # no raise — `messages` is undefined, but script continues

step_2(messages)    # NameError on `messages` — confusing two-stage failure

When to NOT re-raise

Some steps are optional — the rest of the workflow should continue even if this step failed. Logging instead of crashing makes sense:

python

try:
    send_optional_metric()
except Exception as e:
    print(f"metric send failed (continuing): {e}")
# script continues normally

This is judgment per step. "Critical to the workflow" → re-raise. "Nice to have" → log and continue.

Fancier: a step-runner helper

At 4+ steps the per-step pattern gets verbose. A helper:

python

def run_step(name, fn):
    try:
        return fn()
    except Exception as e:
        print(f"{name} failed: {type(e).__name__}: {e}")
        raise

messages = run_step("fetch", lambda: toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {...}))
run_step("create-event", lambda: toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {...}))

Functions you'll write fluently after Auto Intermediate.

Day 19 · ~11 min●

python

try:
    result = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 1})
    messages = result.get("messages", [])
except Exception as e:
    print(f"step 1 (read) failed: {type(e).__name__}")
    raise

try:
    toolset.execute_action(Action.GOOGLECALENDAR_UPDATE_EVENT, {"calendar_id": "primary", "event_id": "missing", "summary": str(messages), "start_datetime": "2026-12-31T10:00:00+00:00", "event_duration_minutes": 30})
except Exception as e:
    print(f"step 2 (write) failed: {type(e).__name__}")
    raise

Each step in its own try/except?

And raise inside the except — re-raises the same error?

Errors in chains — the per-step `try/except`

The pattern:

python

try:
    # step 1
except Exception as e:
    print(f"step 1 failed: {type(e).__name__}")
    raise

try:
    # step 2
except Exception as e:
    print(f"step 2 failed: {type(e).__name__}")
    raise

The diagnostic print + raise combo gives you:

a named failure point in the logs
the original traceback for full context
the script still ends on error (no partial-state continuation)

Why `raise` matters

Without raise, the except swallows the error and the script keeps running. If step 1 actually failed, step 2 would proceed with incomplete data — worse than crashing immediately.

python

try:
    messages = step_1()
except Exception:
    print("step 1 failed")
    # no raise — `messages` is undefined, but script continues

step_2(messages)    # NameError on `messages` — confusing two-stage failure

When to NOT re-raise

Some steps are optional — the rest of the workflow should continue even if this step failed. Logging instead of crashing makes sense:

python

try:
    send_optional_metric()
except Exception as e:
    print(f"metric send failed (continuing): {e}")
# script continues normally

This is judgment per step. "Critical to the workflow" → re-raise. "Nice to have" → log and continue.

Fancier: a step-runner helper

At 4+ steps the per-step pattern gets verbose. A helper:

python

def run_step(name, fn):
    try:
        return fn()
    except Exception as e:
        print(f"{name} failed: {type(e).__name__}: {e}")
        raise

messages = run_step("fetch", lambda: toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {...}))
run_step("create-event", lambda: toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {...}))

Functions you'll write fluently after Auto Intermediate.

Errors in chains — the per-step `try/except`

Why `raise` matters

When to NOT re-raise

Fancier: a step-runner helper

Errors in chains — the per-step `try/except`

Why `raise` matters

When to NOT re-raise

Fancier: a step-runner helper

Errors in chains — the per-step `try/except`

Why `raise` matters

When to NOT re-raise

Fancier: a step-runner helper

Sign up to practice

Errors in chains — the per-step `try/except`

Why `raise` matters

When to NOT re-raise

Fancier: a step-runner helper

Sign up to practice

Errors in chains — the per-step try/except

Why raise matters

When to NOT re-raise

Fancier: a step-runner helper

Errors in chains — the per-step try/except

Why raise matters

When to NOT re-raise

Fancier: a step-runner helper

Errors in chains — the per-step try/except

Why raise matters

When to NOT re-raise

Fancier: a step-runner helper

Sign up to practice

Errors in chains — the per-step try/except

Why raise matters

When to NOT re-raise

Fancier: a step-runner helper

Sign up to practice

Errors in chains — the per-step `try/except`

Why `raise` matters

Errors in chains — the per-step `try/except`

Why `raise` matters

Errors in chains — the per-step `try/except`

Why `raise` matters

Errors in chains — the per-step `try/except`

Why `raise` matters