> For the complete documentation index, see [llms.txt](https://marcylabschool.gitbook.io/swe/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://marcylabschool.gitbook.io/swe/mod-10-capstone/field-guide.md).

# Applied AI Engineering Residency Field Guide

This document is a reference, not a tutorial. It will not teach you Python or FastAPI. What it will do is help you see exactly how large the problem is — and it is smaller than you think — and give you a strategy for tackling it efficiently.

You already know how to program. You know what a loop is, what a function does, what an object is, what a database relationship looks like. None of that changes. The question you are answering over the next five weeks is simply: **how does Python express what I already know how to do in JavaScript?**

***

## Table of Contents

* [Table of Contents](#table-of-contents)
* [Why Learn Python](#why-learn-python)
* [Part 1: Learning Python](#part-1-learning-python)
  * [The Big Idea](#the-big-idea)
  * [How to Learn Python Syntax](#how-to-learn-python-syntax)
  * [Syntax Differences (learn these fast)](#syntax-differences-learn-these-fast)
  * [Design Decisions (spend real time here)](#design-decisions-spend-real-time-here)
* [Part 2: Learning a Web Framework](#part-2-learning-a-web-framework)
  * [Your Task](#your-task)
  * [How to Learn Your Framework](#how-to-learn-your-framework)
  * [Weeks 3-5: Research and Build!](#weeks-3-5-research-and-build)
  * [Ideas for Throwaway Apps to Build](#ideas-for-throwaway-apps-to-build)
* [Part 3: The Project](#part-3-the-project)
  * [Product Specification Document](#product-specification-document)
  * [Capstone Project Team Roles](#capstone-project-team-roles)
    * [Shared Responsibilities](#shared-responsibilities)
  * [Daily Stand Down Updates](#daily-stand-down-updates)
  * [Sprints](#sprints)
    * [Sprint 0 — Ship the MVP](#sprint-0--ship-the-mvp)
    * [Sprint 1 — Build, Test, Learn](#sprint-1--build-test-learn)
    * [Sprint 2 — Refine, Test, Present](#sprint-2--refine-test-present)
  * [The PR Workflow](#the-pr-workflow)

***

## Why Learn Python

You are already a JavaScript engineer. Why does learning Python matter?

> *You stop thinking in JavaScript and start thinking in programming*

**Learning a second language makes you a better programmer.** The most valuable thing about learning Python is not Python. It is what learning any second language teaches you about programming itself. When you have to think carefully about how Python expresses something you already know how to do in JavaScript, you develop a deeper understanding of the underlying concepts. *You stop thinking in JavaScript and start thinking in programming*. That transferable thinking is what allows strong engineers to pick up new languages quickly throughout their careers.

**Python is everywhere and in demand.** It consistently ranks as one of the most widely used programming languages in the world and in 2026, it is the most in demand skill for software engineers. It powers backend systems at companies like Instagram, Spotify, Dropbox, and Reddit. It is the dominant language in data science, machine learning, and AI engineering. If you want to work in any of those areas, or work alongside people who do, Python fluency is a baseline expectation.

**AI runs on Python.** The tools and libraries that power modern AI — TensorFlow, PyTorch, LangChain, Hugging Face — are all Python-first. As AI becomes a more central part of software engineering, knowing Python means you can read, understand, and work with the systems underneath the tools you use. You stop being a consumer of AI and start being an engineer who understands it.

**Python is a strong second language for a software engineer.** JavaScript and Python together cover an enormous range of job opportunities. JavaScript gets you into frontend and full-stack web development. Python gets you into backend engineering, data engineering, automation, scripting, and AI. Many engineering teams use both. Being comfortable in both makes you a more versatile and more hireable engineer.

**You will be able to speak to it in interviews.** Being able to say "I'm comfortable working in both JavaScript and Python" and then demonstrate it is a meaningful signal to a hiring manager. It shows adaptability, curiosity, and a willingness to learn. Those are qualities that get people hired.

***

## Part 1: Learning Python

### The Big Idea

Learning a second programming language is not like learning the first one. The first time, you were learning to think like a programmer. This time, you are learning how to express those same thoughts with new syntax.

Almost everything you need to learn falls into one of two categories:

1. **Syntax differences** — the same concept expressed differently (e.g., indentation instead of curly braces, `def` instead of `function`)
2. **Design decisions** — places where Python made a fundamentally different choice than JavaScript (e.g., strong vs. weak typing, how scope works, how errors are handled)

Category 1 you can pick up in a few hours. Category 2 is worth spending real time on, because it changes how you think about writing code in Python, not just how you write it.

### How to Learn Python Syntax

You do not need a course. You need a good reference and a problem to solve. In order of usefulness:

* **Python Cheatsheet** (<https://labex.io/pythoncheatsheet/>) — fast, scannable, great for syntax lookup. Links to classes and tutorials.
* **LeetCode** ([leetcode.com](https://leetcode.com/problemset/)) — do easy problems you already know how to solve in JavaScript. Your only job is to translate.
* **Official Python documentation** ([docs.python.org](https://docs.python.org/3/tutorial/index.html)) — dense but authoritative. Use the tutorial section to start.

### Syntax Differences (learn these fast)

Work through this list. For each concept, your goal is to be able to answer the guiding question confidently.

**Variables and Data Types**

* How do you declare a variable in Python? How is this different from JavaScript?
* What are Python's primitive data types? How do they map to JavaScript's?
* *Vocab:* `int`, `float`, `str`, `bool`, `None`, dynamic typing

**Functions**

* How do you define a function in Python?
* How does Python handle default parameter values?
* What is the difference between `return` in Python vs. JavaScript?
* *Vocab:* `def`, keyword arguments, positional arguments, `args`, `*kwargs`

**Conditionals**

* How do you write an `if/else` statement in Python?
* What replaces `===` in Python? What about `&&`, `||`, `!`?
* *Vocab:* `elif`, `and`, `or`, `not`, `==`, `is`

**Loops**

* How do you write a `for` loop in Python? How is it different from JavaScript's `for...of`?
* What is a `while` loop in Python?
* How do you loop with an index when you need one?
* *Vocab:* `for`, `while`, `range()`, `enumerate()`, `break`, `continue`

**Lists (Python's Arrays)**

* How do you create, access, and modify a list in Python?
* What list methods should you know? How do they compare to JavaScript array methods?
* What is list comprehension and when would you use it?
* *Vocab:* `list`, `append()`, `pop()`, `len()`, `sorted()`, `map()`, `filter()`, list comprehension

**Dictionaries (Python's Objects)**

* How do you create a dictionary in Python?
* How do you access, add, and remove keys?
* How do you loop over a dictionary?
* *Vocab:* `dict`, `keys()`, `values()`, `items()`, `.get()`

**String Manipulation**

* How does Python handle string formatting? What are f-strings?
* What common string methods should you know?
* *Vocab:* f-strings, `.split()`, `.join()`, `.strip()`, `.replace()`, `.upper()`, `.lower()`

**Error Handling**

* How does Python handle errors? How is this similar to and different from JavaScript's `try/catch`?
* *Vocab:* `try`, `except`, `finally`, `raise`, `Exception`

**File I/O**

* How do you read from and write to a file in Python?
* *Vocab:* `open()`, `with`, `read()`, `write()`, `readlines()`

**Importing Modules**

* How do you import code from another file or library in Python?
* How is this different from JavaScript's `require` and `import`?
* *Vocab:* `import`, `from`, `as`, standard library, `pip`

**Classes and Object-Oriented Programming**

You know OOP from JavaScript. Python's OOP will feel familiar but has its own conventions.

* How do you define a class in Python?
* What is `self` and why does every method take it as the first argument?
* How does inheritance work in Python?
* How do dunder methods work and what are the most important ones?
* *Vocab:* `class`, `__init__`, `self`, `super()`, dunder methods (`__str__`, `__repr__`, `__eq__`), inheritance

***

### Design Decisions (spend real time here)

These are the concepts where Python made a different architectural choice than JavaScript. Most, if not all, programming languages made decisions for each of these areas. Understanding what these choices are will not only make you a more fluent Python programmer, it will help you understand the range of decisions one can make when designing a programming language.

**Scope**

In JavaScript, scope is created by curly braces `{}`. A variable declared inside a block stays inside that block. In Python, scope is created by indentation — but the rules are subtly different. A variable declared inside a `for` loop, for example, is still accessible after the loop ends.

```jsx
// JavaScript
for (let i = 0; i < 3; i++) {
  let x = i * 2;
}
console.log(x); // ReferenceError: x is not defined
```

```python
# Python
for i in range(3):
    x = i * 2
print(x) # prints 4 — x is still accessible
```

* What creates a new scope in Python?
* What is the difference between local, enclosing, global, and built-in scope (LEGB rule)?
* *Vocab:* LEGB rule, `global`, `nonlocal`, namespace

**Strong vs. Weak Typing**

JavaScript is weakly typed — it will try to make sense of almost anything you give it, often converting types automatically in ways that produce surprising results. Python is strongly typed — it will raise an error rather than silently convert types for you.

```jsx
// JavaScript
let val = 'hello';
val += 10;
console.log(val); // prints hello10 — coerces the number 10 into a string
```

```python
# Python
val = 'hello'
val = val + 5 # TypeError: can only concatenate str (not "int") to str
```

* What is the difference between strong and weak typing?
* What is the difference between static and dynamic typing? (Python is both strongly typed and dynamically typed — make sure you understand what that means)
* Why does this matter when you are writing code?
* *Vocab:* strong typing, weak typing, static typing, dynamic typing, type coercion, `type()`, `isinstance()`

**Mutability**

Python makes a clear distinction between mutable and immutable data types. This matters more than you might expect when you start passing data between functions.

* What is the difference between mutable and immutable types in Python?
* What types are mutable? What types are immutable?
* What is a tuple and when would you use one instead of a list?
* *Vocab:* mutable, immutable, `tuple`, `frozenset`, shallow copy, deep copy

**Virtual Environments and Dependency Management**

In JavaScript you have `npm` and `package.json`. Python has its own equivalent system that you need to understand before you can build anything real.

* What is a virtual environment and why do you need one?
* How do you create and activate a virtual environment?
* What is `pip` and how does it compare to `npm`?
* What is a `requirements.txt` file and how does it compare to `package.json`?
* *Vocab:* `venv`, `pip`, `requirements.txt`, `pip freeze`, `activate`

***

## Part 2: Learning a Web Framework

### Your Task

One of the major goals of your Residency is to build a full stack application using Python for your server-side application. Once you’ve learned the basics of Python, the next step is learning one of Python’s web frameworks: **FastAPI**.

Just as JavaScript has frameworks like Express for building web servers, Python has its own web frameworks. The three most popular are Django, FastAPI, and Flask and each were built with different goals in mind:

* **Flask** is a microframework. It gives you almost nothing out of the box — just routing and request handling — and expects you to add what you need. Maximum flexibility, minimum magic.
* **Django** is a full-featured framework. It comes with an ORM, an admin panel, authentication, and a lot of conventions. Maximum structure, less flexibility, faster to build standard things.
* **FastAPI** is a modern, fast framework built specifically for APIs. It uses Python type hints to automatically generate documentation and validate requests. Excellent for building APIs, particularly ones that will connect to AI services.

While each of these frameworks can be used to build a web server, we will all be learning **FastAPI** for a few reasons:

* FastAPI is popular: adoption jumped from 29% to 38% in a single year according to the 2025 JetBrains/Python Software Foundation survey, and job postings for FastAPI grew 150% year-over-year — particularly strong in fintech and AI companies. The job market currently favors Django and FastAPI roughly equally overall, but the trajectory is clearly FastAPI's.
* FastAPI will feel conceptually familiar to Express — you define routes, handle requests, return responses.
  * Django's "batteries included" design (ORM, admin, auth all baked in) is powerful but introduces a lot of magic that conflicts with the mental model-building you prioritize.
  * Flask is barebones and easy to set up but isn’t as relevant in the industry for full stack development meaning you won’t learn common patterns that you will see on the job.

Learning FastAPI (or any of these frameworks for that matter) is necessary for building a full stack application in Python. However, as an academic exercise it will allow you to draw connections between all web server applications, regardless of which language or framework it was built upon. This will allow you to transcend from a software engineer who can build PERN applications to one who can build full stack applications with any language and framework.

***

### How to Learn Your Framework

### Weeks 3-5: Research and Build!

Your goal by end of Week 5 is to have a deployed MVP version of your application built, laying a strong foundation for your final project. This means user authentication and a single resource that users can manage.

Getting to that point with a new framework in a language that you are still learning may seem daunting but learning and building go hand in hand! Here are some steps that we recommend you take to quickly get up to speed with **FastAPI** and get a head start on building your project.

**Step 1: Read the official documentation introduction**

Every framework has a "getting started" or "quickstart" section. Read it before you watch any videos. This gives you the framework's own mental model for how it works.

* FastAPI: <https://fastapi.tiangolo.com/tutorial/>

**Step 2: Build the simplest possible thing**

Build a to-do app, a notes app, or a simple blog. This could be the foundation of your final project or it could be something unrelated. Build something that forces you to touch the core parts of the framework: routing, JSON responses, and a database connection.

The important thing is that you do not get trapped just reading documentation or watching YouTube videos and instead you actually start writing code.

**Step 3: Ask the right questions about your framework**

As you build, make sure you can answer these questions:

* How does routing work? How do you define a URL and connect it to a function?
* How does the framework handle requests and responses?
* How does it connect to a database? Does it have its own ORM or do you bring your own?
* How does it handle authentication? Is it built in or do you add a library?
* How does it compare to Express? What concepts map directly? What is genuinely different?
* What kind of project is this framework best suited for?
* What are its limitations?

**Step 4: Find two or three good resources**

Do not collect twenty resources. Find two or three that are high quality and go deep on them.

Good resource types for framework learning:

* The official documentation (always start here)
* One video tutorial that builds a real app from scratch (not a 10-minute overview)
* One written tutorial that goes deeper on a specific concept you found confusing

Resources to be cautious about:

* Anything more than 3 years old (frameworks change fast)
* Tutorials that skip setting up a database or auth (those are the hard parts)
* AI-generated code you do not understand line by line

***

### Ideas for Throwaway Apps to Build

If you aren’t sure yet about how to build your final project, start with a generic throwaway app. The best throwaway app is one that forces you to touch the parts of the framework you will need for your real project. Once you’ve built this application, it should be easy to translate your learnings to your final project. Here are some ideas:

* **A simple notes app** — create, read, update, delete notes. Covers basic CRUD and routing.
* **A blog with comments** — posts have many comments. Covers a one-to-many relationship.
* **A user authentication app** — register, login, logout, protected routes. Covers auth.

***

## Part 3: The Project

### Product Specification Document

Your product specification document develops continuously first across the first five weeks and then is refined throughout the remainder of the Residency. It is not a document you write once — it is a living artifact that gets sharper as your understanding of the project deepens.

**Week 2: Project Proposal**

Before any framework code is written, your team submits a Project Proposal that includes a project overview, user personas, a feasibility check, and a first draft of user stories. This is not a final spec. It is evidence that you have thought seriously about who you are building for and why. This proposal serves as the foundation of your project’s documentation that will evolve and grow throughout these 10 weeks.

**Weeks 3-4: Informal Development**

While you are building your throwaway apps and making your framework decision, your team should be having ongoing conversations about the actual project. Specifically:

* **Schema:** What tables will you need? What are the relationships? Sketch this out on paper or a whiteboard. It does not need to be formal yet.
* **API contract:** What endpoints will your server expose? What does a request look like? What does the response look like? Talk through this as a team.
* **Wireframes:** Sketch the key screens. They do not need to be polished — rough sketches on paper are fine. The goal is to make sure your team has a shared picture of what you are building before you start building it.

These conversations inform your Week 5 spec. By the time you sit down to write the formal document, you should not be starting from scratch.

**Week 5: Full Product Spec**

Alongside your MVP build, your team formalizes the product spec. The final document includes:

* **Revised personas and user stories** — updated based on anything you learned during Weeks 3-4
* **Schema design** — the structure of your data, finalized
* **API contract** — all endpoints, HTTP methods, request bodies, and expected responses
* **Wireframes** — visual mockups of all key screens
* **Third-party APIs and libraries** — anything external you plan to integrate, with a brief rationale for each

**Weeks 6+: Refinement**

As your project grows and evolves, so should your Product Specification document. Think of this document as the source of truth that reflects the current state of your project.

### Capstone Project Team Roles

Every Capstone project team has three members, each with a distinct role. These roles are fixed for the duration of the project. They are not just titles — each role comes with real responsibilities that the team depends on you to fulfill.

No role is more important than the others. A technically brilliant application that misses its deadlines, loses track of its tickets, or drifts from its user's actual needs is not a successful project. All three roles are essential.

If there is a disagreement between the Tech Lead and the Product Leader that the team cannot resolve, bring it to your Engineering Manager. Do not let it stall your work.

{% tabs %}
{% tab title="Scrum Master / Project Manager" %}
**You own the process.**

You are responsible for keeping the team organized, on track, and accountable. While everyone on the team builds the product, you make sure the team is always clear on what needs to get done, who is doing it, and when it is due.

**Responsibilities**:

* **Sprint Planning**
  * Lead sprint planning at the start of each sprint
  * Work with the team to define sprint goals and break them into specific tasks
  * Create tickets on the GitHub Projects board for every task, with clear descriptions and acceptance criteria
  * Assign tickets to team members and set due dates
* **During the Sprint**
  * Keep the GitHub Projects board up to date — tickets should reflect reality at all times
  * Follow up with teammates on the status of their tickets, especially as deadlines approach
  * Flag any tasks that are at risk of not being completed so the team can adjust
  * Take notes during team meetings and Engineering Manager check-ins
* **Engineering Manager Check-In**
  * You run the weekly Engineering Manager check-in
  * Come prepared with a status update on the sprint board: what is done, what is in progress, what is blocked
  * Flag any deadlines at risk and any unresolved team disagreements that need the Engineering Manager's input
* **Deadlines**
  * Track all Capstone deadlines — not just sprint deadlines but submission deadlines, deck due dates, and user testing sessions
  * Give the team at least 48 hours of notice before any major deadline

**What Good Looks Like**

* The GitHub Projects board is always current and anyone could look at it and understand exactly where the project stands
* No deadline surprises — the team always knows what is coming
* Blockers are surfaced early, not the day before something is due
  {% endtab %}

{% tab title="Product Leader" %}
**You own the "what" and the "why."**

You are responsible for the product vision and the user experience. You make sure the team is always building the right thing — something that actually solves the problem for the people it is designed to serve.

**Responsibilities**

* **Product Vision**
  * Maintain and communicate a clear vision for the product throughout the project
  * Ensure every feature the team builds connects back to the user's actual needs
  * Make final decisions on product questions — what features to prioritize, what to cut, what the user experience should feel like
* **User Research and Feedback**
  * Serve as the primary point of contact with the Industry Stakeholder for your Civic Tech Challenge Area
  * Communicate with the Industry Stakeholder via email to gather feedback on product direction and validate that the solution addresses the real problem
  * Incorporate feedback from user testing sessions into product decisions for the next sprint
  * Bring user insights back to the team in a clear, actionable way
* **Product Spec**
  * Lead the development of the Product Spec Sheet — personas, user stories, API contract, schema design, and wireframes
  * Ensure the spec reflects the team's current understanding of the product and is updated as the product evolves
* **Engineering Manager Check-In**
  * Speak to product decisions made since the last check-in
  * Raise any open questions about product direction that need input

**What Good Looks Like**

* The team always has a clear answer to "who is this for and why would they use it"
* Product decisions are made deliberately and communicated clearly to the team
* User feedback from testing sessions is translated into specific, actionable changes
  {% endtab %}

{% tab title="Tech Lead" %}
**You own the "how."**

You are responsible for the technical quality of the codebase. You make final decisions on how the team builds things and you are accountable for the overall health of the repository.

**Responsibilities**

* **Technical Decision-Making**
  * Make final decisions on technical questions — architecture, framework patterns, how to structure the database, how to implement a feature
  * When the team is unsure how to approach something technically, you drive the decision
  * Document significant technical decisions so the team has a record of why things were built the way they were
* **Code Review**
  * Review and approve all pull requests before they are merged into `main`
  * Leave substantive code review comments — not just approvals
  * Hold the team to the standard that `main` is always stable and nothing broken gets merged
* **Repository Health**
  * Ensure the repository is well-organized and the README is accurate and up to date
  * Own the deployment — make sure the app is deployed and the deployment is stable
  * Ensure automated tests are in place and passing before code is merged
* **Engineering Manager Check-In**
  * Speak to significant technical decisions made since the last check-in
  * Raise any technical blockers that need input or escalation

**What Good Looks Like**

* `main` is always stable — no broken builds, no untested code merged without review
* The team has a clear technical direction and does not spend time relitigating decisions that have already been made
* Pull requests receive thoughtful feedback, not just rubber-stamp approvals
  {% endtab %}
  {% endtabs %}

#### Shared Responsibilities

Regardless of role, every team member is expected to:

* Contribute code throughout the project
* Submit all individual Capstone deliverables (LinkedIn posts, README contributions, presentation sections)
* Attend and participate in Engineering Manager check-ins
* Review teammates' pull requests (the Tech Lead has final approval, but everyone reviews)
* Participate in sprint planning and sprint retros
* Conduct and participate in user testing sessions
* Present their section of the final Engineering Fair presentation

***

### Daily Stand Down Updates

As we move into the project build phase, how we communicate our progress becomes just as important as the code we write. To keep your team aligned, we are adopting a structured Daily Stand Down update format posted in Slack at the end of every working day.

This is not a checklist to prove you were working. It is a tool to help you synthesize your progress, spot risks early, and practice communicating like a professional engineer. Your Scrum Master is responsible for making sure every team member posts their update each day.

{% tabs %}
{% tab title="Completions" %}
**What it is:** What did you actually finish or meaningfully advance today?

**The Golden Rule:** Don't just list the task — include the outcome or insight. What did you learn? What does it unblock?

| Instead of...                  | Write...                                                                                                                                                             |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "Worked on the login page"     | "Got the login form connected to the backend — users can now register and log in. Realized our token wasn't being stored correctly in localStorage; fixed that too." |
| "Did some research on the API" | "Spent time reading the OpenAI API docs and figured out how to structure our prompt to return consistent JSON. Ready to start building the feature tomorrow."        |
| "Fixed a bug"                  | "Fixed the bug where submitting the form twice was creating duplicate database entries — added a check on the backend to prevent it."                                |
| {% endtab %}                   |                                                                                                                                                                      |

{% tab title="Updates" %}
**What it is:** Anything that changed today that your team should know about — schedule shifts, decisions made, feedback received, pivots taken.

**The Golden Rule:** If the plan changed, say so here. This keeps everyone tracking the same roadmap and prevents your teammates from working toward something that is no longer the goal.

| Instead of...                   | Write...                                                                                                                                                                                    |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "We had a meeting"              | "Met with our Industry Stakeholder — she confirmed that users need to be able to filter by date, not just category. Updating our user stories to reflect this."                             |
| "Changed something in the repo" | "Switched our database schema to use a junction table for the many-to-many relationship after talking with the Tech Lead — the previous design wouldn't have supported the filter feature." |
| {% endtab %}                    |                                                                                                                                                                                             |

{% tab title="Focus / Working On" %}
**What it is:** What are you working on next? This is what you are walking into tomorrow with.

**The Golden Rule:** Keep this forward-looking and specific. If a deadline is coming up in the next 48 hours, the tasks leading directly to that deadline should dominate this section.

| Instead of...             | Write...                                                                                                                                      |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| "More backend work"       | "Building the GET /resources endpoint tomorrow — need it done by Wednesday so we can connect the frontend before deployment."                 |
| "Finishing up my feature" | "Writing tests for the auth flow and submitting my PR by end of day tomorrow so the Tech Lead has time to review before the sprint deadline." |
| {% endtab %}              |                                                                                                                                               |

{% tab title="Blockers / Notes" %}
**What it is:** Anything slowing you down or stopping you entirely, and who you need help from.

**The Golden Rule:** Be specific about what you are blocked on, what you have already tried, and who you need. Tag that person directly — blockers should be resolved peer-to-peer first, with escalation to your Engineering Manager only if the team cannot resolve it.

| Instead of...                     | Write...                                                                                                                                                                                                                       |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| "Stuck on my feature"             | "Blocked by @Jordan — need you to merge your branch before I can build on top of it. Can you do that tonight or first thing tomorrow?"                                                                                         |
| "Having issues with the database" | "Can't figure out why my foreign key constraint is failing on insert. Already checked the schema and the data types match. @Alex — I know you dealt with something similar last sprint. Can we pair on this tomorrow morning?" |

**A note on blockers:** Surfacing a blocker early is a professional habit, not an admission of failure. The longer you sit on a blocker without flagging it, the more it risks the whole sprint. If a peer cannot unblock you within 24 hours, escalate to your Engineering Manager.
{% endtab %}
{% endtabs %}

**A Full Example:**

Here is what a strong daily stand down update looks like:

> Completions
>
> * Finished building the POST /reports endpoint — it saves to the database and returns the new record. Tested with Postman, works as expected.
> * Merged Jordan's PR after reviewing — left a comment about the error handling we should add in a follow-up ticket.
>
> Updates
>
> * Talked to our Industry Stakeholder via email — she wants users to be able to flag a report as "urgent." Adding this as a stretch feature ticket on the board.
> * Pushed our Wednesday deployment back to Thursday after checking in with the Tech Lead — we want auth fully tested before we go live.
>
> Focus / Working On
>
> * Writing the frontend form that connects to the POST /reports endpoint
> * Need to sync with Alex tomorrow about how we are handling form validation on the client side
>
> Blockers / Notes
>
> * Blocked by @Alex — waiting on the GET /users endpoint so I can populate the dropdown on the report form. Can you give me an ETA tonight?

**A Few Things to Keep in Mind**

* **Post at the end of every working day**, including remote Fridays. Your Scrum Master will follow up if an update is missing.
* **Blockers go to your teammates first.** Tag the specific person you need. Only escalate to your Engineering Manager if the team cannot resolve it within 24 hours.
* **This structure is a starting point.** As your team finds its rhythm, you have the autonomy to adapt it. If you want to add a "Wins / Shoutouts" section to celebrate each other, do it. Own your communication process and iterate on it.

### Sprints

Weeks 4-9 can be viewed as three distinct "Sprints"

**The Big Picture**

| Sprint       | Weeks     | Goal                                             |
| ------------ | --------- | ------------------------------------------------ |
| **Sprint 0** | Weeks 4–5 | Finish your Product Spec Sheet and ship your MVP |
| **Sprint 1** | Weeks 6–7 | First feature sprint + user testing and feedback |
| **Sprint 2** | Weeks 8–9 | Final feature sprint + presentation              |

#### Sprint 0 — Ship the MVP

**The goal of these two weeks is simple: deploy something real.**

Deployment is not an end-of-project task: it is a Week 5 deadline. Teams that do not have a deployed MVP entering Sprint 1 are already behind.

**Week 4**

* Begin sketching your schema, API contract, and wireframes informally. These do not need to be in their final form yet for every feature you plan on building, but your team should have enough of a vision for the necessary architecture to build the MVP.
* Continue daily code challenges and Python practice

**Week 5**

* Monday: Sprint planning session — define exactly what you're shipping by Friday and break it into daily milestones on your GitHub Projects board
* Build: user auth, one-to-many relationship, deployed `main` branch
* Complete and submit your full Product Spec Sheet alongside your deployed MVP

**Key Deliverables**

* [ ] Complete Product Spec Sheet submitted end of Week 4
* [ ] Deployed MVP — stable `main` branch, live by end of Week 5

#### Sprint 1 — Build, Test, Learn

**You have a deployed MVP. Now make it better.**

Sprint 1 is your first structured opportunity to build features, get real feedback from real users, and use that feedback to make deliberate decisions about what comes next. Every decision your team makes in Sprint 2 should be informed by what you learn this sprint.

The sprint follows a fixed rhythm:

| Day               | Activity                                                     |
| ----------------- | ------------------------------------------------------------ |
| Monday (Day 1)    | Sprint planning — define goals, update GitHub Projects board |
| Wednesday (Day 8) | All sprint changes merged into `main` and deployed           |
| Thursday (Day 9)  | Structured user testing session                              |
| Friday (Day 10)   | Sprint retro                                                 |

**Week 6 (Sprint 1, Week 1)**

* Sprint 1 planning on Monday: define your stretch features, break them into tickets, assign owners
* Each fellow owns feature branches and submits PRs for teammate review — no direct commits to `main`
* Independent build time is the primary mode. Office hours are available daily for unblocking

**Week 7 (Sprint 1, Week 2)**

* All Sprint 1 changes merged and deployed by Wednesday
* Thursday: structured user testing session — your team will be assigned approximately 3 other teams' apps to test. Testing is done via screen recording (Loom or equivalent) with testers narrating their experience aloud. Tester Feedback Forms submitted same day.
* After testing: watch the recordings of people testing *your* app. Complete your Observation Form, identifying 2–3 concrete changes to carry into Sprint 2
* Friday: Sprint 1 retro

**Key Deliverables**

* [ ] GitHub Projects board updated and active at start of Week 6
* [ ] All Sprint 1 changes merged and deployed by Wednesday of Week 7
* [ ] Tester Feedback Forms submitted Thursday of Week 7
* [ ] Observation Forms submitted by end of Friday of Week 7
* [ ] Sprint 1 LinkedIn post (deployed app + public feedback request) — reviewed and approved before posting

#### Sprint 2 — Refine, Test, Present

**Sprint 2 is Sprint 1 with higher stakes.**

You now have real user feedback. Use it. The features you build this sprint should reflect what you learned from testing — not just what your team thought would be cool two weeks ago. Teams that ignore user feedback and build what they originally planned are missing the point of the process.

In addition to taking the user feedback and implementing it to refine your product, you will be presenting your project and Applied AI Residency journey to your peers and stakeholders!

The sprint follows a similar rhythm as Sprint 1 with presentations taking the place of user testing.

| Day               | Activity                                                     |
| ----------------- | ------------------------------------------------------------ |
| Monday (Day 1)    | Sprint planning — define goals, update GitHub Projects board |
| Wednesday (Day 8) | All sprint changes merged into `main` and deployed           |
| Thursday (Day 9)  | Final stakeholder presentations                              |
| Friday (Day 10)   | Sprint retro                                                 |

**Week 8 (Sprint 2, Week 1)**

* Begin building your presentation deck this week — don't wait until Week 9
* Sprint 2 planning on Monday, explicitly informed by user testing feedback from Sprint 1. Your Observation Form should be open in front of you during planning
* Continue owning feature branches and submitting PRs

**Week 9 (Sprint 2, Week 2)**

* All Sprint 2 changes merged and deployed by Wednesday
* Thursday: Final formal presentations with industry stakeholders
* Friday: Sprint 2 retro

**Key Deliverables**

* [ ] GitHub Projects board updated for Sprint 2 at start of Week 8
* [ ] Presentation drafts submitted Friday of Week 8
* [ ] All Sprint 2 changes merged and deployed by Wednesday of Week 9
* [ ] Final presentations submitted by Wednesday EOD of Week 9

### The PR Workflow

Once your team begins building in Week 5, all code goes through a pull request. This is not optional and it is not bureaucracy — it is how real engineering teams work.

**The rules:**

* `main` is always stable. Nothing broken ever gets merged to `main`.
* Every feature lives on its own branch, named `your-name/feature-name` (e.g., `jordan/user-auth`)
* No one merges their own PR. At least one teammate must review and approve it first.
* Code review comments should be substantive. "LGTM" is not a review.

**What good code review looks like:**

* Point out anything you do not understand and ask the author to explain it
* Flag anything that looks like it could break, even if you are not sure
* Suggest a cleaner or more Pythonic way to write something if you see one
* Acknowledge what is working well — a review is a conversation, not just criticism

**On merge conflicts:** You will hit them. They are not emergencies. A merge conflict means two people changed the same part of the codebase and Git cannot automatically decide which version to keep. Resolving them is a skill — one worth learning now, because it comes up in every engineering job.