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.

Schedule-safety mindset — Automation Patterns

Day 16 · ~12 min●

Week 2's primitives — retry, dedup, state — exist for one reason: schedule-safety. The mental test for any automation: would this still be safe if it ran at 9am every day, no human watching?

Three sample scripts. For each, find the line that breaks at the hourly mark.

Script A — sends a daily standup email:

python

toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "team@example.com",
    "subject": "daily standup",
    "body": "good morning",
})

If this fires every hour: 24 emails to your team. Not idempotent — each call creates a new message. The fix: dedup against a seen set keyed by date.

Script B — appends a row with the timestamp:

python

import datetime
row = [str(datetime.datetime.now()), "event"]
append_row(SHEET_ID, row)

The row's content changes every call (timestamp moves). That's actually... fine? Yes — it's append-only logging, so it's meant to grow. But: there's no upper bound. After a year of hourly runs: 8,760 rows. Schedule-safe but unbounded. Add a retention policy.

Script C — reads top 5 unread emails and replies:

python

emails = fetch_emails(query="is:unread", max_results=5)
for e in emails:
    send_reply(e["id"], "Got it.")

At 9am: 5 unread → 5 replies → those 5 are now read. At 10am: a new unread arrives → 1 reply. Sane.

But: if the recipient replies back and that thread becomes unread again? Loop: bot → reply → human → reply → bot → ... Add a check that the message wasn't sent by you.

So the audit is more than "is it idempotent"?

Exactly. Idempotency is one axis. Others: bounded growth, infinite loops, time-zone drift, quota cost compounding, partial-failure recovery. Today: practice the audit on three scripts.

Schedule-safety — the audit checklist

Before deploying any script to a schedule, walk through:

1. Idempotency

Does a re-run with no input change produce the same world state?

✗ send_email daily — duplicates daily.
✓ update_event(id=ABC, summary="daily") — same world state.
✓ send_email only after dedup-checking the date hasn't been processed.

2. Boundedness

Does the script's footprint grow forever?

✗ Append a row hourly with no cap → 8,760 rows/year, 87,600 in a decade.
✓ Append, then trim to last 1000 rows once per week.
✓ Use a separate Sheet per month and rotate.

3. Loops

Does the script's output trigger its own input?

✗ Reply to all unread → your reply becomes part of someone's unread → they reply → loop.
✓ Only reply to unread emails not from yourself.
✓ Set a marker (label, header, etc.) so the script knows what it has already seen.

4. Time-zone drift

Is "today" computed the same way at 9am every day?

✗ datetime.now() returns local time; if the runner's TZ flips (DST), "today" shifts an hour.
✓ datetime.now(timezone.utc) — UTC has no DST.
✓ Use the user's explicit TZ from a config dict.

5. Quota cost

Does hourly amplification of cost stay reasonable?

✗ Loop fetches 1000 emails, scans each → 1000 calls × 24 hours = 24,000 calls/day.
✓ Track "last seen" id; only fetch new emails (incremental — tomorrow's lesson).

6. Failure recovery

If today's run fails, can tomorrow's run catch up?

✗ Script processes "yesterday's items" — a missed run loses a day.
✓ Script reads last_processed_id, processes everything since — missed runs catch up automatically.

The mental hat

Before a script ships to a schedule, put on the malicious-input hat: imagine the worst plausible scenario, walk through every line. The audit catches what testing won't.

What week 3 will fix

This week's lessons hand you the tools the audit demands:

Tomorrow — incremental processing (fix #5 and #6)
Day 18 — failure self-alerts (so a 3am crash pings you)
Day 19 — configuration (move recipients/thresholds out of code)
Day 20 — pre-flight validation (catch malformed input before side effects)
Day 21 — synthesis combining all the above

Day 16 · ~12 min●

Week 2's primitives — retry, dedup, state — exist for one reason: schedule-safety. The mental test for any automation: would this still be safe if it ran at 9am every day, no human watching?

Three sample scripts. For each, find the line that breaks at the hourly mark.

Script A — sends a daily standup email:

python

toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "team@example.com",
    "subject": "daily standup",
    "body": "good morning",
})

If this fires every hour: 24 emails to your team. Not idempotent — each call creates a new message. The fix: dedup against a seen set keyed by date.

Script B — appends a row with the timestamp:

python

import datetime
row = [str(datetime.datetime.now()), "event"]
append_row(SHEET_ID, row)

Script C — reads top 5 unread emails and replies:

python

emails = fetch_emails(query="is:unread", max_results=5)
for e in emails:
    send_reply(e["id"], "Got it.")

At 9am: 5 unread → 5 replies → those 5 are now read. At 10am: a new unread arrives → 1 reply. Sane.

But: if the recipient replies back and that thread becomes unread again? Loop: bot → reply → human → reply → bot → ... Add a check that the message wasn't sent by you.

So the audit is more than "is it idempotent"?

Exactly. Idempotency is one axis. Others: bounded growth, infinite loops, time-zone drift, quota cost compounding, partial-failure recovery. Today: practice the audit on three scripts.

Schedule-safety — the audit checklist

Before deploying any script to a schedule, walk through:

1. Idempotency

Does a re-run with no input change produce the same world state?

✗ send_email daily — duplicates daily.
✓ update_event(id=ABC, summary="daily") — same world state.
✓ send_email only after dedup-checking the date hasn't been processed.

2. Boundedness

Does the script's footprint grow forever?

✗ Append a row hourly with no cap → 8,760 rows/year, 87,600 in a decade.
✓ Append, then trim to last 1000 rows once per week.
✓ Use a separate Sheet per month and rotate.

3. Loops

Does the script's output trigger its own input?

✗ Reply to all unread → your reply becomes part of someone's unread → they reply → loop.
✓ Only reply to unread emails not from yourself.
✓ Set a marker (label, header, etc.) so the script knows what it has already seen.

4. Time-zone drift

Is "today" computed the same way at 9am every day?

✗ datetime.now() returns local time; if the runner's TZ flips (DST), "today" shifts an hour.
✓ datetime.now(timezone.utc) — UTC has no DST.
✓ Use the user's explicit TZ from a config dict.

5. Quota cost

Does hourly amplification of cost stay reasonable?

✗ Loop fetches 1000 emails, scans each → 1000 calls × 24 hours = 24,000 calls/day.
✓ Track "last seen" id; only fetch new emails (incremental — tomorrow's lesson).

6. Failure recovery

If today's run fails, can tomorrow's run catch up?

✗ Script processes "yesterday's items" — a missed run loses a day.
✓ Script reads last_processed_id, processes everything since — missed runs catch up automatically.

The mental hat

Before a script ships to a schedule, put on the malicious-input hat: imagine the worst plausible scenario, walk through every line. The audit catches what testing won't.

What week 3 will fix

This week's lessons hand you the tools the audit demands:

Tomorrow — incremental processing (fix #5 and #6)
Day 18 — failure self-alerts (so a 3am crash pings you)
Day 19 — configuration (move recipients/thresholds out of code)
Day 20 — pre-flight validation (catch malformed input before side effects)
Day 21 — synthesis combining all the above

Schedule-safety — the audit checklist

1. Idempotency

2. Boundedness

3. Loops

4. Time-zone drift

5. Quota cost

6. Failure recovery

The mental hat

What week 3 will fix

Schedule-safety — the audit checklist

1. Idempotency

2. Boundedness

3. Loops

4. Time-zone drift

5. Quota cost

6. Failure recovery

The mental hat

What week 3 will fix

Schedule-safety — the audit checklist

1. Idempotency

2. Boundedness

3. Loops

4. Time-zone drift

5. Quota cost

6. Failure recovery

The mental hat

What week 3 will fix

Sign up to practice

Schedule-safety — the audit checklist

1. Idempotency

2. Boundedness

3. Loops

4. Time-zone drift

5. Quota cost

6. Failure recovery

The mental hat

What week 3 will fix

Sign up to practice