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.

Idempotency: predict — Automation Foundations

Day 13 · ~12 min●

Today is a thinking lesson, not a code one. The pattern: imagine a script runs once at 9am, then runs again at 10am — same script, same code, no manual changes. What happens?

python

# Script A — read
messages = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 5})
print(len(messages.get("messages", [])))

Run A at 9am: prints 5. Run A at 10am: prints 5. Same outcome. A is idempotent — repeating doesn't compound.

python

# Script B — send
toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "boss@co.com",
    "subject": "daily report",
    "body": "...",
})

Run B at 9am: one email sent. Run B at 10am: another email sent. Now there are two. Different outcome. B is NOT idempotent.

So reads are safe to repeat, writes aren't?

Mostly. With nuance:

Pure reads (FETCH, LIST, GET): always idempotent. Safe to retry.
Pure writes that don't have a uniqueness key (SEND, APPEND, naive CREATE): not idempotent. Re-runs duplicate.
Writes with a uniqueness key or a if not exists check (think: CREATE_OR_GET, UPDATE_BY_KEY): idempotent if you provide the key consistently.

Why does this matter for week 2?

Because retry-on-error is a normal pattern. If your script fails halfway through, you re-run. If the script wasn't designed for that, you create the same row twice, send the same email twice, charge the same card twice. Knowing which half of your code is and isn't idempotent is the difference between safe automation and a phone call from accounting.

Idempotency — "running this twice produces the same outcome"

Formally: an operation is idempotent if applying it twice has the same effect as applying it once.

f(f(x)) == f(x) for any x

For scripts: running the script a second time should leave the world in the same state as running it once.

Reads are always idempotent

Fetching, listing, getting, querying — these don't change anything on the server. Run them as many times as you like.

Writes are usually NOT idempotent

Send an email twice → 2 emails. Append a row twice → 2 rows. Create an event twice → 2 events with the same name (different IDs).

Making writes idempotent

The pattern: include a uniqueness key the API can use to recognize duplicates.

Email send: include a Message-ID header you control. (Most APIs don't deduplicate on send; you'd have to track sent IDs in your own state — see day 14.)
Sheet append: check if the row already exists before appending. (Day 14 covers this.)
Event create: Calendar supports a client-supplied iCalUID that makes create-or-update behaviour easy.
Stripe-style "idempotency key": some APIs accept an explicit Idempotency-Key header — repeated calls with the same key return the same response without re-executing.

Predict-then-verify mindset

Before running a write loop, ask:

If this loop ran twice, would I have one of each thing or two of each thing?
If the network drops mid-run and I retry, would I have a partial duplicate?

If the answer is "two" or "partial duplicate", you don't have idempotency — and you need to add it before this script runs unattended.

The full design pattern (state files, dedup keys, retry-with-backoff) lives in Auto Intermediate. For this week: just recognize whether a script you're writing is idempotent.

Day 13 · ~12 min●

Today is a thinking lesson, not a code one. The pattern: imagine a script runs once at 9am, then runs again at 10am — same script, same code, no manual changes. What happens?

python

# Script A — read
messages = toolset.execute_action(Action.GMAIL_FETCH_EMAILS, {"max_results": 5})
print(len(messages.get("messages", [])))

Run A at 9am: prints 5. Run A at 10am: prints 5. Same outcome. A is idempotent — repeating doesn't compound.

python

# Script B — send
toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "boss@co.com",
    "subject": "daily report",
    "body": "...",
})

Run B at 9am: one email sent. Run B at 10am: another email sent. Now there are two. Different outcome. B is NOT idempotent.

So reads are safe to repeat, writes aren't?

Mostly. With nuance:

Pure reads (FETCH, LIST, GET): always idempotent. Safe to retry.
Pure writes that don't have a uniqueness key (SEND, APPEND, naive CREATE): not idempotent. Re-runs duplicate.
Writes with a uniqueness key or a if not exists check (think: CREATE_OR_GET, UPDATE_BY_KEY): idempotent if you provide the key consistently.

Why does this matter for week 2?

Idempotency — "running this twice produces the same outcome"

Formally: an operation is idempotent if applying it twice has the same effect as applying it once.

f(f(x)) == f(x) for any x

For scripts: running the script a second time should leave the world in the same state as running it once.

Reads are always idempotent

Fetching, listing, getting, querying — these don't change anything on the server. Run them as many times as you like.

Writes are usually NOT idempotent

Send an email twice → 2 emails. Append a row twice → 2 rows. Create an event twice → 2 events with the same name (different IDs).

Making writes idempotent

The pattern: include a uniqueness key the API can use to recognize duplicates.

Email send: include a Message-ID header you control. (Most APIs don't deduplicate on send; you'd have to track sent IDs in your own state — see day 14.)
Sheet append: check if the row already exists before appending. (Day 14 covers this.)
Event create: Calendar supports a client-supplied iCalUID that makes create-or-update behaviour easy.
Stripe-style "idempotency key": some APIs accept an explicit Idempotency-Key header — repeated calls with the same key return the same response without re-executing.

Predict-then-verify mindset

Before running a write loop, ask:

If this loop ran twice, would I have one of each thing or two of each thing?
If the network drops mid-run and I retry, would I have a partial duplicate?

If the answer is "two" or "partial duplicate", you don't have idempotency — and you need to add it before this script runs unattended.

The full design pattern (state files, dedup keys, retry-with-backoff) lives in Auto Intermediate. For this week: just recognize whether a script you're writing is idempotent.

Idempotency — "running this twice produces the same outcome"

Reads are always idempotent

Writes are usually NOT idempotent

Making writes idempotent

Predict-then-verify mindset

Idempotency — "running this twice produces the same outcome"

Reads are always idempotent

Writes are usually NOT idempotent

Making writes idempotent

Predict-then-verify mindset

Idempotency — "running this twice produces the same outcome"

Reads are always idempotent

Writes are usually NOT idempotent

Making writes idempotent

Predict-then-verify mindset

Sign up to practice

Idempotency — "running this twice produces the same outcome"

Reads are always idempotent

Writes are usually NOT idempotent

Making writes idempotent

Predict-then-verify mindset

Sign up to practice