Use a repeatable method for learning, experimenting, reviewing, and communicating technical work.

Learning and project practices

Technical skill grows fastest when students can explain what they tried, what happened, and what they will change next. Use this page with every lesson and project.

Before coding

Write a short experiment card:

Field Question
Question What are you trying to find out or build?
Inputs What data, users, sensors, or files are involved?
Expected result What would a successful run look like?
Constraints What must the system not do?
Test Which normal, edge, and failure cases will you check?

Start with the smallest version that can answer the question. A rule, hand-written example, or tiny dataset is often a better first step than a large model.

During an experiment

  1. Make one meaningful change at a time.
  2. Record the environment, data source, random seed, and important settings.
  3. Keep inputs and outputs free of secrets and private information.
  4. Save the exact error instead of paraphrasing it.
  5. Compare against a simple baseline.
  6. Stop when a result could affect a person, account, money, safety, or hardware; ask for review before continuing.

Evidence ladder

Do not treat one successful example as proof. Build evidence in layers:

  1. Example: the smallest known-good case works.
  2. Variation: inputs, wording, units, or conditions change and the result remains understandable.
  3. Edge case: empty, extreme, missing, or unexpected input is handled.
  4. Failure case: the system fails safely and reports the limitation.
  5. Independent check: another person or a separate test confirms the result.
  6. Out-of-scope statement: the README says where the project must not be used.

Explain results precisely

Separate these statements:

  • Observation: “The chart shows 8 of 10 values below 20.”
  • Interpretation: “The values appear lower on the second day.”
  • Hypothesis: “A shorter practice session may explain the change.”
  • Claim: “Shorter practice causes lower performance.”

The last statement requires a study designed to test causation. Data analysis should not silently turn an observation into a cause.

Review checklist

Before sharing a notebook or demo, verify:

  • a clean environment can run the setup;
  • cells or scripts run in order from a fresh start;
  • units, labels, and data sources are stated;
  • tests include normal, edge, and failure cases;
  • generated or model output is checked against evidence;
  • privacy, consent, accessibility, and safety boundaries are documented;
  • sources, datasets, and collaborators are credited; and
  • the next improvement is specific and achievable.

Reflection prompts

Answer at least three:

  1. What surprised you?
  2. Which assumption was weakest?
  3. Which result would you not trust yet?
  4. What information would reduce uncertainty?
  5. What would happen if the input distribution changed?
  6. Who could be harmed by a wrong result?
  7. Which part should remain a rule or human decision?

References