Computer Science Principles: Computation, Data, and Society

Before any coding, your child learns the five ideas that the entire rest of the course keeps reusing: algorithm, sequence, selection, iteration, decomposition, and abstraction. They practice by hand-tracing simple step-by-step instructions (pseudocode and flowcharts), not by writing code.

1. The definitions of algorithm, sequence, selection, iteration, decomposition, and abstraction+

   Students correctly define, in their own words, the six core terms of this unit, algorithm, sequence, selection, iteration, decomposition, and abstraction, matching each term to a short example given during Day 1-8 instruction.

2. Sequential execution of a pseudocode algorithm and its effect on variable values+

   Given a short pseudocode algorithm using only sequence, students correctly complete a trace table showing the value of every variable after each line executes.

3. Selection and iteration control structures and their effect on variable state across multiple steps+

   Given a pseudocode algorithm containing one selection (if/else) or one iteration (loop) structure, students correctly trace it through a trace table, correctly updating the counter or condition variable at each pass.

4. Sequence, selection, and iteration as structural categories of algorithmic control flow+

   Students correctly identify and label instances of sequence, selection, and iteration within an unfamiliar pseudocode or flowchart algorithm they have not seen before.

5. Off-by-one logic errors in loop boundary conditions+

   Given a pseudocode algorithm with a deliberately inserted off-by-one loop-boundary error, students trace the algorithm to locate the exact line and value at which the actual output diverges from the intended output, and explain in one sentence why that line causes the divergence.

6. Decomposition of a problem into independently justifiable sub-steps+

   Students decompose a stated real-world problem into an ordered set of named sub-steps at a level of detail sufficient for another student to diagram, and justify in writing why each boundary between sub-steps was drawn where it was.

7. Abstraction as deliberate concealment of implementation detail, and its tradeoffs for the user+

   Students explain, using a specific abstraction they did not encounter in class (e.g., a rideshare app's 'request ride' button, a thermostat's set-temperature dial, or a vending machine's item button), what detail is hidden from the user, why hiding that detail benefits the user, and one situation in which that hiding could put the user at a disadvantage.

8. Robustness of a decomposition's boundaries under changed problem constraints+

   Given two different correct decompositions of the same original problem produced by classmates, students compare the two decompositions and identify which one would be more robust if the problem's constraints changed slightly (e.g., the input list could now be empty), stating the specific constraint change that breaks one decomposition and not the other.

9. Correspondence between flowchart and pseudocode representations of the same algorithm+

   Students translate a given flowchart into pseudocode (or a given pseudocode listing into a flowchart) such that every box/line in one notation corresponds to an identifiable line/box in the other, without changing the underlying logic.

Your child starts actually writing Python: variables, if/elif/else, for loops, while loops. The point this unit hammers home is that most beginner mistakes are notation mistakes, not thinking mistakes — a correct flowchart can still produce a Python crash, and that's a spelling problem, not a logic problem.

1. Variable assignment using = as distinct from mathematical equality+

   Given a short Python snippet using = for assignment, students predict the value stored in a named variable after each line executes, distinguishing assignment from mathematical equality.

2. Sequential state change across multiple assignment statements+

   Students trace a Python program containing sequential variable reassignment (e.g. a running total updated across several lines) and correctly state the final printed value.

3. Deterministic branch selection in if/elif/else+

   Given an unseen if/elif/else block and a specific input value, students trace execution to determine which single branch runs and justify why the earlier branches did not.

4. Python error types: IndentationError, NameError, TypeError+

   Students classify a Python runtime error message (IndentationError, NameError, or TypeError) by its type and identify the specific line and likely cause without being told which error category it is.

5. For-loop accumulator pattern+

   Students write a for loop that iterates a specified number of times to accumulate a running total, given a new but structurally similar word problem not seen in class.

6. While-loop termination conditions and the infinite-loop error+

   Given a while loop that never terminates, students identify why the boolean condition never becomes False and rewrite the loop so it terminates correctly.

7. Selecting the appropriate control structure (sequence/selection/iteration) for an unfamiliar problem specification+

   Given a word-problem specification never seen in class, students decide unassisted whether the solution requires a conditional, a loop, both, or neither, and justify that choice before writing code.

8. An original program integrating conditionals and loops, checked against its own predicted trace+

   Students write and run an original Python program from a word-problem spec that combines at least one conditional and one loop, then compare their program's actual run output to their own hand-traced predicted output and explain any discrepancy.

9. The distinction between syntax errors and logic errors in a program with correct underlying algorithmic intent+

   Students explain, in their own words using a specific traced example, why a program with correct algorithmic logic can still crash, distinguishing a syntax error from a logic error.

Your child moves from one-variable-at-a-time to lists: storing many values together and writing one loop that processes all of them, using the index as the link between position and value. It closes with cleaning a genuinely messy dataset with no rulebook provided.

1. 0-based list indexing+

   Given a list and a target position, retrieve the correct 0-based index needed to access the first, last, and nth element.

2. For-item-in-list iteration syntax+

   Execute a for-loop that iterates over every element of a list and prints each value, without using an explicit index variable.

3. Index-based vs. item-based iteration over the same list+

   Compare the for-item-in-list pattern and the for-i-in-range(len(list))-with-list[i] pattern for the same task, and explain in writing when the index-based form is necessary rather than optional.

4. The relationship between list length and valid index range+

   Classify a given code snippet that indexes into a list as either producing a valid access or triggering an IndexError, by comparing the index used to the list's valid index range.

5. Reading an IndexError traceback to locate the faulty index value+

   Given a Python traceback showing an IndexError, infer the specific line and index value responsible for the failure and state what value would have been valid instead.

6. Accumulator-variable loop pattern for sum, count, or max+

   Implement an accumulation pattern (running total, running count, or running maximum) using a for-loop over a list, given only a problem statement and no skeleton code.

7. Data loss and mutation consequences of sort/filter operations on a list+

   Predict, then verify by running code, whether the original order and removed values of a list survive after a sort() or filter operation, and state the general rule for when data is recoverable.

8. List cleaning, iteration, and accumulation applied to an unfamiliar composite data structure+

   Given a novel dataset structure never used in this course (e.g., a list of dictionaries representing sensor readings with timestamps), design and write a cleaning-and-summary program that removes invalid entries, preserves a record of what was removed, and reports at least three summary statistics.

9. Irrecoverable information loss caused by filtering decisions made without foresight of future use+

   Given a real-world scenario where a filtered dataset is later needed for a purpose the filtering did not anticipate (e.g., a school later wants to know how many students scored exactly 0, but 0 was treated as invalid and discarded), argue what information was permanently lost and what design change would have prevented the loss.

10. Strings as sequences of characters, compared to lists+

    Exemplify the difference between a list and a string as sequence types by identifying two operations (e.g., indexing, iteration) that work identically on both and one operation that does not.

11. The causal link between an error message's content and the code fix it implies+

    Summarize, in a written explanation accompanying the summative program, one specific bug encountered, quoting the exact error message and explaining how its wording pointed to the fix.

Your child learns to name a repeated block of code as a function — the same 'hide the detail, expose the name' move as Unit 1's abstraction and Unit 2's print()/input(). It ends with taking a messy 40-line program someone else 'wrote' and reorganizing it into functions.

1. The function signature (name, parameters, return type by inference) as a contract separate from implementation+

   Given a 5-8 line function definition with a docstring-free header, students state in one sentence what the function does (its contract) without reading its body line by line.

2. Parameter passing and return value flow across a function call boundary+

   Students trace a program by hand, recording the value of each parameter and each variable at each function call and return, for a program with at least two nested function calls.

3. Local vs. global scope and the bugs caused by conflating them+

   Students explain why a function that modifies a global variable inside its body produces different output than a caller expects, using a specific mis-scoped code example.

4. Duplication in code as the signal that a function boundary belongs there+

   Given a duplicated-logic program from Unit 3 (the same 4-line block appearing 3 times with different variables), students identify which lines are truly identical across all three copies versus which lines merely look similar but differ in a way that matters for correctness.

5. Function definition with parameters and a return value, as a direct replacement for duplicated code+

   Students write a function with at least one parameter and a return statement that correctly replaces a specified block of duplicated code, verified by running it against the original program's output.

6. Decomposition of a program into functions along its 'natural' task boundaries+

   Given an unfamiliar 40-line program students have not seen before, students propose a decomposition into 3-5 functions, name each function, specify its parameters and return value, and justify why each boundary was drawn where it was rather than elsewhere.

7. Tradeoffs between alternative function decompositions of the same program+

   Students compare two different valid decompositions of the same program (one function-per-loop vs. one function-per-task) and explain what each version makes easier and harder to change later.

8. The four named function-related bug categories and their distinguishing symptoms+

   Students diagnose the specific cause of a broken program from among four seeded bug categories (missing return, mismatched argument order, mismatched argument count, scope confusion) by running it and reading the error or wrong output, without being told which category applies.

9. Transfer of function-decomposition reasoning to an unfamiliar problem domain+

   Given a program from a domain never used in this course (e.g., a recipe-scaling calculator or a simple grading-curve tool), students design a function-based decomposition from scratch and defend it in writing against a specific alternative decomposition a partner proposes.

10. Full refactor of an unstructured program into a function-based design, plus a feature extension that tests whether the design supports change+

    Students refactor a given unstructured 40-line program into at least three functions with parameters and return values, extend it with one new feature using their new function structure, and write a rationale explaining why each function boundary was chosen over at least one plausible alternative.

Your child stops thinking of a file as 'a picture' or 'a song' and starts thinking of it as bits whose meaning depends entirely on which encoding rule is being used to read them. This covers binary place value, bytes, lossy versus lossless compression, and bias in how data gets collected in the first place.

1. Binary-decimal place value conversion for 8-bit values+

   Convert a positive whole number up to 255 between binary and decimal representation using place value.

2. ASCII character encoding of byte values+

   Decode a given sequence of 8-bit bytes into ASCII text using a provided ASCII lookup table.

3. The relationship between a bit pattern and the encoding convention applied to it+

   Explain why the same 8-bit pattern can correctly represent a number, an ASCII character, or a component of a color, depending on which encoding the reading program assumes.

4. Lossy vs. lossless compression as different information-preservation guarantees+

   Compare a lossless and a lossy compression approach applied to the identical short artifact by identifying what information is discarded in the lossy version and what is preserved in the lossless version.

5. Data collection and encoding choices embedded in a specific real dataset+

   Given a small, unfamiliar real dataset (CSV), identify at least one specific choice made during data collection or encoding that constrains what conclusions can validly be drawn from it.

6. Design tradeoffs in creating a new binary encoding scheme+

   Design an original small-scale binary encoding scheme (fewer than 8 bits) for a novel, self-chosen symbol set, and justify whether the chosen bit length is sufficient.

7. The distinction between sampling bias and encoding bias in data collection+

   Classify a given real-world data collection scenario as an example of sampling bias, encoding bias, both, or neither, distinguishing it from a simple data-entry error.

8. The multi-step ASCII decoding procedure (bits to decimal to character)+

   Summarize, in the student's own words, the sequence of decoding steps used to turn a raw byte sequence into readable ASCII text.

This builds the layer picture of the internet: client and server, packets, IP addresses, DNS, routing, TCP/IP, HTTP/HTTPS, and the tradeoffs between bandwidth, latency, and fault tolerance. It closes by using free browser developer tools to trace what actually happens when a real web page loads.

1. The client-server-DNS-routing-packet layer model of a network request+

   Given a diagram of a network request, students correctly label each layer (client, DNS, IP routing, packet, server) using the standard term for each.

2. The distinction between a protocol (a rule set) and physical network infrastructure+

   Students explain why a protocol is a set of agreed-upon rules rather than a physical device, using the turn-taking/etiquette analogy taught in class.

3. Packet reassembly using sequence numbers despite out-of-order arrival+

   Given a scrambled set of index-tagged packet fragments (some delayed, none lost), students reconstruct the original message and explain why packet order at arrival does not need to match send order.

4. TCP's retransmission/reliability guarantee as the cause of differing outcomes between two contrasted network scenarios+

   Students compare a network scenario with TCP's reliability guarantees against an otherwise identical scenario without them, and identify which specific behavior (retransmission of lost packets) accounts for the difference in outcome.

5. Bandwidth, latency, and fault tolerance as distinct causes of network performance problems+

   Students classify a set of short network scenarios by whether the described problem is best explained by bandwidth, latency, or fault tolerance, distinguishing cases that superficially resemble each other.

6. The real end-to-end sequence of network layers for a specific, novel URL+

   Using only free browser developer tools, students trace and annotate the actual sequence of steps (DNS lookup, IP routing, packet exchange, server response) that occurs when a real, previously-unexamined URL is requested.

7. Application of the layer model (client, DNS, routing, packet, server) to an unfamiliar, real-world infrastructure failure scenario+

   Given a novel scenario describing a network failure that does not match any case discussed in class (e.g., a submarine cable cut affecting one region's routing), students predict which named layers are affected and which continue functioning, and justify the prediction using the layer model.

8. Accountability for harm in a decentralized network, applied to a specific real incident not covered in class+

   Given a scenario about responsibility when something on the internet causes harm, students construct an argument identifying which specific actor(s) in the layer chain (ISP, DNS provider, server owner, platform, or none uniquely) bore responsibility in a real, previously undiscussed incident, and defend the argument against the objection that decentralization means no one is responsible.

9. The function of DNS as name-to-address translation+

   Students recall the definition of DNS as the system that translates human-readable domain names into IP addresses.

10. Packet-switching's fault-tolerance advantage over single-stream transmission, as an integrated explanation+

    Students summarize, in their own words, why breaking a message into packets sent independently is more fault-tolerant than sending the entire message as one continuous stream, integrating the routing, packet-reassembly, and fault-tolerance concepts taught across the unit.

This unit asks whether any system can be fully secure and argues no — anything that stores or moves data creates something attackable. It covers encryption (explicitly reframed as encoding with a secret key), human-layer attacks like phishing and social engineering, network-layer attacks like packet sniffing and man-in-the-middle, and the tradeoffs behind personal data collection and targeted ads.

1. Symmetric-key encryption as a two-way encoding/decoding procedure using a shared key+

   Given a stored piece of plaintext and a simple substitution/XOR-style key example, students execute the encoding and decoding steps by hand to produce ciphertext and recover the original plaintext.

2. The five named attack-vector terms and their mechanisms+

   Students correctly recall the definitions of phishing, malware, social engineering, packet sniffing, and man-in-the-middle attack, matching each term to its one-sentence mechanism.

3. The three-way classification of attack vectors by layer+

   Given a short, previously unseen incident description, students classify which single attack category (human/social-engineering, network-layer, or encryption/key-compromise) it represents, citing the specific textual evidence that rules out the other two.

4. The checkable tells that distinguish legitimate communication from phishing+

   Students compare a genuine and a fabricated (phishing) message side by side and explain which specific, checkable features (sender domain, link destination, urgency framing) distinguish them, rather than relying on surface polish.

5. The distinction between breaking encryption and compromising a different point in the encrypted pipeline+

   Students explain why a fully encrypted communication channel can still be compromised, by identifying the specific point in the data pipeline (key storage, key transmission, or an unencrypted endpoint) where a described breach actually occurred.

6. The usability-cost-risk tradeoff underlying data-collection decisions+

   Before receiving the formal usability-cost-risk framework, students examine two contrasting real-world data-collection scenarios and generate their own criterion for what makes one collection practice more or less concerning than the other.

7. The reasonableness of a specific organization's security tradeoff, evaluated against evidence in an incident report+

   Given a completely novel data-breach report not discussed in class, students argue in writing whether the affected organization's security tradeoff was reasonable, using specific evidence from the report about cost, usability, and risk rather than asserting a general judgment of competence.

8. The relationship between an app's stated functionality/permissions and the personal data it is likely collecting+

   Students infer which specific personal data an unfamiliar app or service is likely collecting and why, based only on the app's stated functionality and permission requests, without being told the answer.

9. The distinction between a vector-specific mitigation and a generic security recommendation+

   Students differentiate between a mitigation that closes a specific named vulnerability and a generic security recommendation that does not name what it blocks, when evaluating sample mitigation proposals.

The last 16 days pull everything together into one Python program and one written argument about a real computing system's effect on people. The central skill is telling apart three things: a bug, an unequal outcome with no evidence of intent (disparate impact), and an unequal outcome with evidence of intent (disparate treatment) — and separately, realizing that a system 'working as specified' doesn't settle whether it should exist that way.

1. The distinction between disparate impact (outcome evidence) and disparate treatment (intent evidence) as two different classes of claim requiring two different kinds of evidence+

   Given a real-world computing system's design description and de-identified outcome data disaggregated by group, the student correctly labels each of five provided claims about the system as supported by outcome evidence, supported by intent evidence, or unsupported by the given evidence.

2. The three-way evidentiary test (bug vs. disparate impact vs. disparate treatment) applied to an unfamiliar case+

   Given a new, previously undiscussed case of an algorithmic system with both design rationale and outcome data, the student determines whether the available evidence supports a claim of bug, disparate impact, or disparate treatment, and identifies what additional evidence (if any) would be needed to support a stronger claim.

3. A function-based data-processing pipeline that computes a disaggregated summary statistic from a list of records+

   The student writes a function that takes a list of records (dictionaries or tuples) loaded from a real dataset and a group-membership key, and returns a per-group summary statistic (e.g., selection rate, average value) using iteration and conditionals from Units 2-3.

4. Adaptation of a taught function-based aggregation pattern to a structurally similar but surface-different dataset+

   Given a dataset with a different shape or grouping variable than the one used in the worked example (e.g., three groups instead of two, or a numeric threshold instead of a category), the student adapts their disaggregation function to compute the correct per-group statistic without re-deriving the loop structure from scratch.

5. The relationship between unequal computing/network access (digital divide) and sampling bias in who is represented in a dataset+

   The student explains, in a labeled two-column comparison, one specific way the digital divide (unequal access to devices, bandwidth, or skills) could bias which population is represented in a given real-world dataset, using vocabulary from Unit 5 (data representation) and Unit 6 (network access).

6. Obligations imposed by specific open-source software licenses on reuse and redistribution+

   Given two real open-source license summaries (e.g., MIT and a copyleft license), the student identifies at least one obligation each license imposes on someone who reuses or redistributes the code, and states which license would apply if the student redistributed a modified version commercially.

7. The distinction between spec-conformance ('does it work') and social-impact justification ('should it exist this way') as applied to one specific, named real-world system+

   The student writes a structured argumentative paragraph evaluating whether a named real-world computing system 'should' exist in its current form, distinguishing this claim explicitly from whether the system 'works as specified,' and supporting the should-exist claim with cited evidence rather than stated opinion.

8. Cumulative course vocabulary applied in context to a novel case rather than recited in definition form+

   The student correctly uses at least four distinct pieces of vocabulary from four different prior units (e.g., iteration from Unit 3, function/parameter from Unit 4, encoding from Unit 5, protocol/packet or attack surface from Unit 6-7) in context within the written report, applying each term to the specific case rather than defining it generically.

9. The digital-divide-to-sampling-bias mechanism applied to a domain, dataset shape, and framing not used anywhere in instruction+

   Given a description of a data-collection system from a domain never discussed in class or offered on the report's case list (e.g., a municipal smart-traffic sensor network or a university wearable-fitness research study), with NO causal-chain diagram, worksheet, or framing question supplied, the student identifies whether and how unequal access to devices, connectivity, or digital skill could bias which people or places are represented in the resulting dataset, and names the specific access factor responsible using Unit 5/6 vocabulary without being told which prior concept applies.