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.

Side effect: send — Automation Foundations

Day 9 · ~11 min●

Week 1 was reads — calls that ask the API for information. Week 2 is writes — calls that change something on the other side. Send an email, append a row, create an event. The first one: send.

python

toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "yourself@example.com",
    "subject": "zuzu-day-8",
    "body": "hello from python",
})

A real email lands in a real inbox. Side effects are committed — there's no "undo".

So before week 2, my code couldn't really break anything?

Reads have minor effects (rate limit, quota slot) but no permanent change. Writes do. Pause-and-check before running any new send. Especially with loops.

And how do we verify the send happened?

Round trip. Send the message, then search the inbox for the subject we used. If the API call worked AND Gmail indexed the message, the search finds it. The grading post-script does this — a small retry loop in case Gmail's index hasn't caught up yet.

Side effects — calls that change external state

Reads return information. Writes do something — send a message, create a row, modify an event. Once the call returns successfully, the change is committed. No rollback.

The shape

Same execute_action shape as week 1, just a different action slug:

python

toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "someone@example.com",
    "subject": "My subject",
    "body": "plain text body",
})

recipient_email, subject, body are required. (Optional: cc, bcc, attachments.)

Pause before you loop

A loop that calls a write API is a loop that creates real-world artifacts. Consider:

python

for i in range(100):
    toolset.execute_action(Action.GMAIL_SEND_EMAIL, {...})    # 100 emails

A classic week-2 panic is a typo'd recipient and 100 emails to your boss. As a rule for early lessons:

send to yourself until you're confident
start with range(2), not range(100)
print before send: print(f"about to send to {recipient}") and visually confirm before unleashing

Eventual consistency

Gmail's send is fast. The corresponding messages.list index update is eventually consistent — your sent email may take 5-30 seconds to be searchable by subject. The grading post-script accounts for this with a retry loop:

python

import time
for _ in range(5):
    found = toolset.execute_action(Action.GMAIL_FETCH_EMAILS,
                                   {"query": "subject:zuzu-day-8"})
    if found.get("messages"):
        break
    time.sleep(2)
assert found.get("messages"), "sent email not found in inbox"

When authoring side_effect verifications, retry-with-sleep is the standard pattern. (The lesson-authoring-rules.md document captures this for future authors.)

Day 9 · ~11 min●

Week 1 was reads — calls that ask the API for information. Week 2 is writes — calls that change something on the other side. Send an email, append a row, create an event. The first one: send.

python

toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "yourself@example.com",
    "subject": "zuzu-day-8",
    "body": "hello from python",
})

A real email lands in a real inbox. Side effects are committed — there's no "undo".

So before week 2, my code couldn't really break anything?

Reads have minor effects (rate limit, quota slot) but no permanent change. Writes do. Pause-and-check before running any new send. Especially with loops.

And how do we verify the send happened?

Side effects — calls that change external state

Reads return information. Writes do something — send a message, create a row, modify an event. Once the call returns successfully, the change is committed. No rollback.

The shape

Same execute_action shape as week 1, just a different action slug:

python

toolset.execute_action(Action.GMAIL_SEND_EMAIL, {
    "recipient_email": "someone@example.com",
    "subject": "My subject",
    "body": "plain text body",
})

recipient_email, subject, body are required. (Optional: cc, bcc, attachments.)

Pause before you loop

A loop that calls a write API is a loop that creates real-world artifacts. Consider:

python

for i in range(100):
    toolset.execute_action(Action.GMAIL_SEND_EMAIL, {...})    # 100 emails

A classic week-2 panic is a typo'd recipient and 100 emails to your boss. As a rule for early lessons:

send to yourself until you're confident
start with range(2), not range(100)
print before send: print(f"about to send to {recipient}") and visually confirm before unleashing

Eventual consistency

python

import time
for _ in range(5):
    found = toolset.execute_action(Action.GMAIL_FETCH_EMAILS,
                                   {"query": "subject:zuzu-day-8"})
    if found.get("messages"):
        break
    time.sleep(2)
assert found.get("messages"), "sent email not found in inbox"

When authoring side_effect verifications, retry-with-sleep is the standard pattern. (The lesson-authoring-rules.md document captures this for future authors.)

Side effects — calls that change external state

The shape

Pause before you loop

Eventual consistency

Side effects — calls that change external state

The shape

Pause before you loop

Eventual consistency

Side effects — calls that change external state

The shape

Pause before you loop

Eventual consistency

Sign up to practice

Side effects — calls that change external state

The shape

Pause before you loop

Eventual consistency

Sign up to practice