• 1. Students can identify input / output data for particular problems, and write them down formally as type annotations.

  • 1.1. Simple types: numbers, strings, booleans, images, tables
  • 1.2. Parametric types: Lists, Trees
  • 1.3. Limitations of signatures in capturing effects.

• 2. Students can write thorough test suites for functions of varying complexity.

  • 2.1. What is a test? How do I write one?
  • 2.2. What makes a set of tests "good" -- edge cases, coverage, concise.

• 3. Students can clearly articulate, in precise language, documentation strings for functions.

  • 3.1. What is a docstring for?
  • 3.2. What should be in, and not be in, a good docstring?

• 4. Students can solve smaller problem in the service of solving larger problems, without being told the breakdown ahead of time.

  • 4.1. Separate types of data should have separate functions
  • 4.2. Data transformations expressed as a sequence of simpler operations

• 5. Students identify types of data that can be represented using tables, and write programs using common table operations.

• 6. Students can write programs using mutable and immutable variables and mutable and immutable data.

  • 6.1. Loops over list with a single mutable variable
  • 6.2. Difference between variable and value mutation.

• 7. Students can identify pros and cons of using given data to solve the desired problem, and identify and defend privacy issues in problems presented to them without being told there is a privacy issue to identify.

  • 7.1. Given the functional requirements of the program to be built and an explicitly identified and concrete second objective (privacy, fairness, accessibility), students can identify ways in which the given data can be used to solve the primary problem while falling short on the secondary objective.

  • 7.2. Given the functional requirements of the program to be built, students independently identify a way that using the given data to solve the problem would fall short on a second objective (privacy, fairness, accessibility) when prompted to look for one.

  • 7.3. Given the functional requirements of the program to be built, students independently identify a way that using the given data to solve the problem would fall short on a second objective (privacy, fairness, accessibility) without a prompt after practice following a checklist.

  • 7.4. Given a definition of privacy and examples of privacy problems using that definition, students can identify new privacy issues of the same kind when cued to look for a privacy problem.

  • 7.5. Relying on prior definitions of privacy, students can independently identify new privacy problems of the same kind given the cue to look for a problem but not the explicit cue to look for a privacy problem.

  • 7.6. Given experience with specific solutions previously presented to them for privacy problems, students can suggest similar mitigations for new privacy problems.

• 8. Given a technical problem, students can (a) identify the stakeholders, (b) identify values and interests at stake for each stakeholder, (c) discuss conflicts of values, and (d) identify modifications that would mitigate conflicts of values.

  • 8.1. Given a technical problem, students can (a) identify stakeholders relative to a certain problem (e.g. privacy), including at least one stakeholder not listed in the problem set-up. Notes: Stakeholders are relative to the concern you are addressing, so have to do it with a very specific concern (such as privacy). For privacy in particular, students should recognize that people related to or friends with a named party might also have a stake in the privacy of the named party. Keep in mind that there are some stakeholders who are directly in contact with the technology and others who might be affected by the technology without being in contact with it.

  • 8.2. Given a technical problem, students can (a) identify at least one stakeholder not listed in the problem setup and (b) identify at least one value and/or interest at stake for each stakeholder.

  • 8.3. Given a technical problem, students can (a) identify the stakeholders, including some not listed in the problem setup and (b) identify at least one value and/or interest at stake for each stakeholder and (c) identify conflicts between the values and/or interests of stakeholders.

  • 8.4. Given a technical problem, students can (a) identify the stakeholders, including some not listed in the problem setup and (b) identify at least one value and/or interest at stake for each stakeholder, (c) identify conflicts between the values and/or interests of stakeholders and (d) recognize resolutions to value conflicts.

• 9. Students learn to work with others while solving problems.

Assessable Outcomes by Week / Assignment​

Lecture Backwards Design​