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.

Multi-tool orchestration with helpers — Automation Patterns

Day 27 · ~12 min●

A script that talks to two tools — Tasks and Calendar — quickly accumulates boilerplate. Each tool has its discovery step, its response-shape quirks, its result.get(...) defensive reads.

The ugly version:

python

# add a task
lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
items = lists.get("items") or lists.get("response_data", {}).get("items", [])
toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {
    "tasklist_id": items[0]["id"],
    "title": "task A",
})

# add a calendar event
toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
    "calendar_id": "primary",
    "summary": "event A",
    "start_datetime": "2026-12-31T10:00:00+00:00",
    "event_duration_minutes": 30,
})

The helper version:

python

def add_task(title):
    lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
    items = lists.get("items") or lists.get("response_data", {}).get("items", [])
    return toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {
        "tasklist_id": items[0]["id"],
        "title": title,
    })

def add_event(summary):
    return toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
        "calendar_id": "primary",
        "summary": summary,
        "start_datetime": "2026-12-31T10:00:00+00:00",
        "event_duration_minutes": 30,
    })

# orchestration reads cleanly
add_task("task A")
add_event("event A")

The main flow names what it's doing. The plumbing is in the helpers.

When do I extract a helper?

When you'd write the same lines twice. Today, with two tools and one call each, helpers are arguably overkill. With three tools and 2-3 calls each, they're essential. Pre-emptive extraction before you have repeated calls is over-engineering; extraction after you've copied a block is good hygiene.

Cache + helper — combine?

Yes. Yesterday's caching pattern fits inside the helper:

python

_cache = {}

def add_task(title):
    if "tasklist_id" not in _cache:
        lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
        items = lists.get("items") or lists.get("response_data", {}).get("items", [])
        _cache["tasklist_id"] = items[0]["id"]
    return toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {
        "tasklist_id": _cache["tasklist_id"],
        "title": title,
    })

Now add_task is fast on call 2+. Every call site benefits without knowing about the cache.

Multi-tool orchestration with helpers

The pattern

python

def tool_a_action(args):
    # discovery, defensive reads, the actual call
    ...

def tool_b_action(args):
    ...

# orchestration
result_a = tool_a_action(args)
intermediate = transform(result_a)
result_b = tool_b_action(intermediate)

Each helper hides one tool's quirks. The orchestration is at the level of intent — which tool to call, in what order, with what data.

Anatomy of a good helper

python

def add_task(title, notes=None):
    """Add a task to the user's default task list."""
    if "tasklist_id" not in _cache:
        lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
        items = lists.get("items") or lists.get("response_data", {}).get("items", [])
        if not items:
            raise RuntimeError("no task lists")
        _cache["tasklist_id"] = items[0]["id"]
    
    args = {"tasklist_id": _cache["tasklist_id"], "title": title}
    if notes:
        args["notes"] = notes
    
    result = toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, args)
    return result.get("task", {}).get("id") or result.get("id") or result.get("response_data", {}).get("id")

Five responsibilities, all hidden from callers:

Discovery — find tasklist (cached)
Argument shape — caller passes title, helper builds the dict
Optional fields — notes only appears in the args if provided
Defensive read — try multiple response shapes
Return the useful field — id, not the whole response dict

Helpers + retry + structured logs

Reliability primitives compose into helpers naturally:

python

def add_task(title):
    last_error = None
    for attempt in range(1, 4):
        try:
            log("add_task.attempt", attempt=attempt, title=title)
            id = ... # the actual call
            log("add_task.ok", attempt=attempt, id=id)
            return id
        except Exception as e:
            last_error = e
    raise last_error

Now every caller of add_task automatically gets retry + structured logs. The orchestration loop stays simple.

When NOT to extract

Used once, not reused. Premature extraction adds friction without payoff.
The call site is already short. A 2-line tool call doesn't need a helper that's 4 lines of definition.
The helper's name doesn't add clarity. def do_thing(x): return action(x) adds no value over inline action(x).

File-level helpers

Beyond ~5 helpers, move them to a separate file (automation_helpers.py) and from automation_helpers import add_task. That's Python Patterns territory; for v1 lessons, top-of-file is enough.

Day 27 · ~12 min●

A script that talks to two tools — Tasks and Calendar — quickly accumulates boilerplate. Each tool has its discovery step, its response-shape quirks, its result.get(...) defensive reads.

The ugly version:

python

# add a task
lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
items = lists.get("items") or lists.get("response_data", {}).get("items", [])
toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {
    "tasklist_id": items[0]["id"],
    "title": "task A",
})

# add a calendar event
toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
    "calendar_id": "primary",
    "summary": "event A",
    "start_datetime": "2026-12-31T10:00:00+00:00",
    "event_duration_minutes": 30,
})

The helper version:

python

def add_task(title):
    lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
    items = lists.get("items") or lists.get("response_data", {}).get("items", [])
    return toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {
        "tasklist_id": items[0]["id"],
        "title": title,
    })

def add_event(summary):
    return toolset.execute_action(Action.GOOGLECALENDAR_CREATE_EVENT, {
        "calendar_id": "primary",
        "summary": summary,
        "start_datetime": "2026-12-31T10:00:00+00:00",
        "event_duration_minutes": 30,
    })

# orchestration reads cleanly
add_task("task A")
add_event("event A")

The main flow names what it's doing. The plumbing is in the helpers.

When do I extract a helper?

Cache + helper — combine?

Yes. Yesterday's caching pattern fits inside the helper:

python

_cache = {}

def add_task(title):
    if "tasklist_id" not in _cache:
        lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
        items = lists.get("items") or lists.get("response_data", {}).get("items", [])
        _cache["tasklist_id"] = items[0]["id"]
    return toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, {
        "tasklist_id": _cache["tasklist_id"],
        "title": title,
    })

Now add_task is fast on call 2+. Every call site benefits without knowing about the cache.

Multi-tool orchestration with helpers

The pattern

python

def tool_a_action(args):
    # discovery, defensive reads, the actual call
    ...

def tool_b_action(args):
    ...

# orchestration
result_a = tool_a_action(args)
intermediate = transform(result_a)
result_b = tool_b_action(intermediate)

Each helper hides one tool's quirks. The orchestration is at the level of intent — which tool to call, in what order, with what data.

Anatomy of a good helper

python

def add_task(title, notes=None):
    """Add a task to the user's default task list."""
    if "tasklist_id" not in _cache:
        lists = toolset.execute_action(Action.GOOGLETASKS_LIST_TASK_LISTS, {})
        items = lists.get("items") or lists.get("response_data", {}).get("items", [])
        if not items:
            raise RuntimeError("no task lists")
        _cache["tasklist_id"] = items[0]["id"]
    
    args = {"tasklist_id": _cache["tasklist_id"], "title": title}
    if notes:
        args["notes"] = notes
    
    result = toolset.execute_action(Action.GOOGLETASKS_CREATE_TASK, args)
    return result.get("task", {}).get("id") or result.get("id") or result.get("response_data", {}).get("id")

Five responsibilities, all hidden from callers:

Discovery — find tasklist (cached)
Argument shape — caller passes title, helper builds the dict
Optional fields — notes only appears in the args if provided
Defensive read — try multiple response shapes
Return the useful field — id, not the whole response dict

Helpers + retry + structured logs

Reliability primitives compose into helpers naturally:

python

def add_task(title):
    last_error = None
    for attempt in range(1, 4):
        try:
            log("add_task.attempt", attempt=attempt, title=title)
            id = ... # the actual call
            log("add_task.ok", attempt=attempt, id=id)
            return id
        except Exception as e:
            last_error = e
    raise last_error

Now every caller of add_task automatically gets retry + structured logs. The orchestration loop stays simple.

When NOT to extract

Used once, not reused. Premature extraction adds friction without payoff.
The call site is already short. A 2-line tool call doesn't need a helper that's 4 lines of definition.
The helper's name doesn't add clarity. def do_thing(x): return action(x) adds no value over inline action(x).

File-level helpers

Beyond ~5 helpers, move them to a separate file (automation_helpers.py) and from automation_helpers import add_task. That's Python Patterns territory; for v1 lessons, top-of-file is enough.

Multi-tool orchestration with helpers

The pattern

Anatomy of a good helper

Helpers + retry + structured logs

When NOT to extract

File-level helpers

Multi-tool orchestration with helpers

The pattern

Anatomy of a good helper

Helpers + retry + structured logs

When NOT to extract

File-level helpers

Multi-tool orchestration with helpers

The pattern

Anatomy of a good helper

Helpers + retry + structured logs

When NOT to extract

File-level helpers

Sign up to practice

Multi-tool orchestration with helpers

The pattern

Anatomy of a good helper

Helpers + retry + structured logs

When NOT to extract

File-level helpers

Sign up to practice