Checklist

Stanford project-quarter survival checklist

A practical playbook for Stanford undergrads and coterm students running three project courses on a ten-week quarter clock, where the demo always lands the same week as the midterm.

Built for Stanford University · Undergrads and masters students juggling project-heavy STEM courses.

Progress

0 of 12 tasks complete

Set the quarter clock

Ten weeks moves fast, so chart where every demo, milestone, and exam collides before week two ends.

Plot all demos and milestones on a ten-week gridQuarters compress everything, so mark each project deliverable, P-set due date, and exam on one grid and circle the weeks where two demos overlap.~40 minPick which course gets your A-gameYou cannot ship three flagship projects equally; decide now which one earns extra polish and which two ship at solid-but-good-enough.~25 minClaim a recurring late-evening roomBook the same Green Library or Huang basement slot weekly so crunch nights do not start with a search for an outlet and a whiteboard.~20 min

Frame each project before coding

Half a quarter's pain comes from building the wrong thing fast; spend the first sessions deciding the right thing.

Write a one-page spec per projectState the deliverable, the grading rubric in your own words, and the single feature that must work for the demo to count.~45 minCarve the project into commit-sized chunksBreak the build into tasks each small enough to finish and commit in one sitting, then order them so a partial build still demos.~35 minAgree the team interface on day oneSettle who owns which module and what the function signatures between them are, so two people are not rewriting the same boundary in week six.~30 min

Pair, build, and commit in rhythm

Steady shipping beats heroic all-nighters; make commits and pairing the default cadence.

Pair-program the gnarliest modulePut two people on the highest-risk component with a driver and navigator, swapping every 25 minutes so the hard part gets two brains.~90 minCommit on a branch every working chunkPush a small, named commit each time a chunk passes, so a broken merge the night before the demo is a one-command rollback, not a rebuild.~15 minRun a Wednesday integration dry runMerge every branch mid-week and do a full run-through; finding the integration bug on Wednesday beats finding it during the Friday demo.~60 min

Land the demo and bank the lesson

The demo is graded on what works live, so rehearse it and then capture what you would never repeat.

Rehearse the demo path end to endRun the exact click-through you will show, on the machine you will present from, so no live surprise eats your grade.~30 minFreeze a known-good build before the deadlineTag a working version the night before and stop adding features; ship the stable build, not the ambitious broken one.~20 minWrite a five-line postmortemNote what cost you the most hours this project so the next quarter's startup-pace crunch repeats fewer mistakes.~20 min

Common mistakes

Treating the ten-week quarter like a sixteen-week semester and starting projects in week four
Polishing all three projects equally until none of them is actually finished
Coding for a week with no commits, then losing it all to one bad merge before the demo
Agreeing module ownership informally, so two teammates silently rewrite the same interface
Adding one more feature the night before instead of freezing a build that already works

Pro tips

Decide your one A-game course early and let the other two ship at good-enough
Order tasks so a half-finished project still has something live to demo
Tag a known-good build the night before and present from that, not from HEAD
Run the full integration on Wednesday so Friday holds no merge surprises
Keep a running list of what wasted hours so each quarter's crunch gets shorter

FAQ

How should I start the Stanford project-quarter survival checklist?

Start with the first phase, then run one timed Study Spaces sprint before adding more tasks. The goal is execution, not a perfect plan.

What should I do if I fall behind?

Copy the remaining tasks, pick the highest-score or highest-deadline item, and restart with one focused block.

How often should I review progress?

Review after each sprint and once at the end of the week so the next session starts with a clear first task.

Browse resources

Use it now

Turn this page into a live sprint

Start the matching room for Stanford University, then use the sprint plan as the first task and recap script.

Stanford project-quarter survival checklist
Focus target: Stanford University
Block 1 (25 min): closed-book recall or one timed practice set.
Break (5 min): mark confusing items without opening a new task.
Block 2 (25 min): correct misses and write the next first step.
Done: one score/error note plus one queued task for tomorrow.

Start Stanford University roomResource list Compare methods