Midterm Review Studio

• Tacit knowledgeKnowledge that is hard to write down or extract. It is why you cannot learn a codebase from docs alone.
• Working hypothesesThe goal is a working model of how (part of) a system works, tested like any other hypothesis.
• Static vs. dynamic gatheringStatic: read, search, navigate (IDE). Dynamic: build it, run it, change it, run it again.
• ProbesPrints, structured logging, debuggers: observe, control, or lightly manipulate execution.
• Entry pointsWhere execution starts: main, OS launch, I/O events, request handlers, test runners.
• Share what you learnUpdate the README or a developer wiki (Mermaid diagrams), so the knowledge stops being tacit.

• MeasurementThe empirical, objective assignment of numbers according to a rule derived from a model, to characterize an attribute.
• Software quality metricIEEE 1061: a function whose inputs are software data and whose output is a value interpretable as a degree of quality.
• Three kinds of qualitiesSoftware (functionality, security, maintainability), process (on-time, velocity), people (satisfaction, wellbeing).
• ValidityConstruct (measuring what we intend), internal (the cause is the one we think), external (generalizes).
• ReliabilityThe same measurement repeated gives similar results.
• Three trapsStreetlight effect, McNamara fallacy, Goodhart's law. Know all three by name and by example.

// newest tests added by the team

• Why process?Make progress observable, control change, catch defects early. Fixing a defect costs more the later it is found.
• Milestones vs. deliverablesA milestone is a clear end point of a task (for the manager). A deliverable is a result handed to the customer.
• Waterfall → Lean → AgileWaterfall: phases in sequence. Lean (Toyota): build only what is needed, when needed. Agile: incremental, inspect-and-adapt, collaborative, customer-involved.
• Scrum elementsProduct backlog, sprint backlog, sprint planning, daily scrum, sprint review, retrospective, increment.
• KanbanVisualize work in columns, limit work in progress.
• INVESTA good user story is Independent, Negotiable, Valuable, Estimable, Small, Testable.

• Tuckman's stagesForming, storming, norming, performing. Teams dip before they climb; norming is where you agree how to work.
• Communication expectationsA quality-of-service guarantee: how soon you reply, which channel for what, when you are unavailable.
• Running a meetingSet the agenda. Start on time, end on time. End with action items.
• Good issuesContext, the problem or request, a proposed solution or next steps, @mentions, labels, and close them with "closes #n".
• Good pull requestsSmall, explicit about what and why, written for anyone in the company, with feedback given thoughtfully.
• Asking for help"I am trying to ___ so that ___. I am running into ___. I have looked at ___ and tried ___."

• What testing isExecuting code on sample inputs in a controlled environment to find bugs, check requirements, and prevent regressions.
• Dijkstra's limit"Testing shows the presence, not the absence, of bugs."
• LevelsUnit (one function), integration (components together), system / end-to-end (the whole thing as a user sees it).
• OraclesWhat tells you an execution was wrong: an assertion, a crash, a differential run against another implementation, a previous version (regression).
• TDDWrite the failing test first, make it pass, refactor. Tests as specifications.
• CoverageStatement, branch, path, and more. 100% coverage is not 100% correctness, and chasing it invites Goodhart's law.

• Levels of abstractionRequirements (what), architecture (high-level how), design (detailed how), code.
• Design vs. architectureDesign: how do I add a menu item? Architecture: how do I make it easy to add menu items? Architecture is the primary carrier of quality attributes.
• Why document it?Blueprint for the system, artifact for early analysis, basis for communication and for reasoning about change.
• ViewsEvery view has a purpose and shows only what that purpose needs: static (modules, dependencies), dynamic (runtime interaction), deployment.
• Five stylesPipes and filters, object-oriented, event-driven, blackboard, layered. Know an example of each.
• NotationSuitable for purpose, usually boxes and arrows, with a legend, and consistent.

• Rice's theoremAny non-trivial property of program behavior is undecidable, so every static analysis is incomplete, unsound, or both.
• Sound vs. completeSound: no false negatives (if it says safe, it is safe). Complete: no false positives (every warning is real). You trade one for the other.
• Static analysisReasons about all possible executions from source, conservatively. Warnings may be false alarms.
• Dynamic analysisReasons about executions actually observed (coverage, profiling, sanitizers). Definitely happened, but only on the inputs you ran.
• Tool classesLinters (shallow, style), pattern-based bug finders (SpotBugs, ErrorProne), type-based checkers (Checker Framework: nullness, taint, units), inference tools (Infer).
• In CIA good tool is fast, has few false positives, and gives actionable messages, or developers will turn it off.

• What an agent isLLM (predicts text) + loop (observe, act again) + tools (act on the world). Autocomplete suggests a line, chat gives an answer, an agent does a task.
• Context is everythingThe model knows only what is in its context window: system prompt, instructions file, tool definitions, files you point at, tool results, your request. Only files survive a session.
• The harnessPrompt, tools, hooks, permissions, subagents, MCP. You do not build one; you specialize a general one for your project.
• What the evidence saysSWE-bench scores overstate correctness; agent PRs are accepted less often than human ones; METR found developers 19% slower while believing they were faster.
• Delegate by riskHow fast would a wrong answer surface, and what would it cost? Four levels of confidence: "done" < tests pass < correct < understood.
• Three debtsTechnical (in the code), cognitive (in people), intent (in artifacts never written down). AI can cut the first while growing the other two.
• WorkflowExplore → Plan → Implement → Commit. Scoped prompts, acceptance criteria, a project instructions file, commits as checkpoints.
• SecurityUntrusted input + privileged action = risk. Prompt injection, invented packages (slopsquatting), least privilege. Instructions are advice; hooks and permissions are enforced.

The real exam has multiple-choice questions on the concepts from lecture and multi-part short-answer scenarios. These are in the same style, not the same questions. Multiple choice gives instant feedback; for the scenarios, write your answer first, then reveal the outline and compare.