Prove
LiveProof-of-Work · Oct–Nov: every verified proof counts. 35 days leftAll outcomes
Skills

Design Programs Step by Step (Systematic Program Design)

15 weeks · 2 milestones

Systematic Program Design (UBC (videos on YouTube, starters on GitHub)), then one project of your own. Part of the Varsity Curriculum: Computer Science.

Milestone map

Milestone map

2 milestones

Do the course work in public

7–13 weeks (8–10 hrs/week)

Take Systematic Program Design for free and do the starter problems with the design recipe (signature, purpose, tests, template). Keep everything in one public repo or notebook as you go. The edX version has a paid certificate. The free videos and starters are enough.

Proof required

Link your public repo or notebook with the starter problems with the design recipe (signature, purpose, tests, template), and a screenshot or log showing the self-check passed.

What gets checked

  • Every function has a signature, purpose and tests that pass.
  • Data definitions come before the functions that use them.
  • Helper functions are split out when one function does two jobs.

Common mistakes

  • Copying posted answers: verifiers read the history.
  • Skipping the self-check, then asking for review too early.

Powstik Guide

A public repo or notebook with the starter problems with the design recipe (signature, purpose, tests, template).

Steps

  1. Make a public repo or notebook first.
  2. Do one unit at a time and commit after each.
  3. Run the self-check: Solve the starter problems; every check-expect must pass.
  4. Write a short README: what is here and how to run it.
  5. Ask three people who know the topic to check it.

Template

README
Course: Systematic Program Design (UBC (videos on YouTube, starters on GitHub))
What is here:
How to run it:
Self-check result:
What was hardest:

What gets sent back

  • No history, just one big upload.
  • Self-check not shown.
  • Code that does not run from the README.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Every function has a signature, purpose and tests that pass.
  • Data definitions come before the functions that use them.
  • Helper functions are split out when one function does two jobs.
  • Ask one question about a choice in the code; the answer should be clear.

You'll sign in first, then come straight back here.

Build an interactive Racket program

1–3 weeks (5–8 hrs/week)

Use what you learned. Make a small world program (a game or animation) built with the design recipe. Keep it small enough to finish in about two weeks.

Proof required

Link a small world program (a game or animation) built with the design recipe, with a README that says how to run or read it.

What gets checked

  • It runs in DrRacket with no errors.
  • Every function shows the design recipe.
  • The world state is a clear data definition.

Common mistakes

  • A project too big to finish.
  • A demo that only works on your machine.

Powstik Guide

A small world program (a game or animation) built with the design recipe.

Steps

  1. Write one line: what it does and for whom.
  2. Build the smallest version that works.
  3. Test it on someone else's machine or with someone else reading it.
  4. Write the README.
  5. Ask three people to check it.

Template

README
What it does:
Who it is for:
How to run it:
What I would do next:

What gets sent back

  • Does not run from the README.
  • Not clearly the person's own work.
  • Claims more than it does.

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • It runs in DrRacket with no errors.
  • Every function shows the design recipe.
  • The world state is a clear data definition.
  • Check that the work is the person's own.

You'll sign in first, then come straight back here.