Skip to content

Data Thinking

Computational thinking traditionally starts with the algorithm. Data thinking insists you start one step earlier — with the evidence the algorithm will consume. A perfectly correct program fed skewed, stale, or unrepresentative data produces confident nonsense. In an era where most decisions are data-mediated and most AI systems are only as good as their training sets, reasoning carefully about data is no longer a specialist skill. It is a core part of thinking computationally.

Data as evidence, not as truth

The single most useful mental move is to treat every dataset as evidence produced by a process, not as a neutral window onto reality. A table of customer complaints is not a picture of customer sentiment — it is a record of who was angry enough, and able, to file a complaint through a specific channel. The gap between what the data measures and what you wish it measured is where most analytical errors live.

Three questions expose that gap quickly:

  • What generated this? Every value was created by some instrument, form, logging call, or human judgment. That generating process has quirks: a sensor that saturates, a dropdown that forces a choice, a default that most users never change.
  • What is missing, and why? Absent rows are rarely random. Patients who never returned, transactions that failed before logging, users who churned before the survey — the silence is itself a signal.
  • Who is not in here? Coverage gaps become discrimination the moment a model trained on the data makes decisions about the people it never saw.

Bias and representativeness

Bias in data is not a moral accusation; it is a structural fact about how the sample relates to the population you care about. The classic failure is selection bias — the data that was easiest to collect systematically differs from the data you needed. A hiring model trained on past “successful” employees learns the demographics of past hiring decisions, not the traits of good work.

Representativeness is about a specific target population and a specific question. The same dataset can be perfectly representative for one question and badly biased for another. Always name the population before judging the sample.

Watch for these recurring patterns:

  • Survivorship bias — you only see the cases that made it far enough to be recorded. Reinforcing aircraft where returning planes were hit is the famous inversion.
  • Measurement bias — the instrument systematically over- or under-reports (a scale that reads 2 kg heavy, a survey question that leads the respondent).
  • Temporal drift — the world moved but the data did not. A fraud model trained on 2023 patterns degrades as fraudsters adapt.
  • Aggregation traps — a trend that holds in every subgroup can reverse when the groups are combined (Simpson’s paradox). Always check whether a headline number hides opposing sub-stories.

The data lifecycle

Thinking computationally about data means thinking about its whole lifecycle, because errors introduced at any stage propagate downstream and are expensive to detect later.

    flowchart LR
    A[Generation] --> B[Collection]
    B --> C[Cleaning and Transformation]
    C --> D[Analysis and Modeling]
    D --> E[Interpretation]
    E --> F[Action and Feedback]
    F --> A
  

Each stage adds assumptions. Collection decides what is representable at all. Cleaning is where subjective calls — how to treat outliers, how to impute missing values, how to bucket categories — quietly become “the data.” The loop matters most: actions taken on the data change the world, which changes future data. A predictive-policing model that sends patrols to a neighborhood then records more arrests there, confirming its own prior. Recognizing these feedback-through-action loops is where data thinking meets systems thinking.

A practical data-audit checklist

Before trusting any dataset for a decision, walk this list. It takes minutes and prevents the most common and expensive mistakes.

Provenance

Where did each field come from? Who or what generated it, when, and for what original purpose? Data repurposed from a system it was not designed for is a frequent source of subtle error.

Population and coverage

Name the population you care about. Estimate who or what is systematically under-represented or absent. Ask whether the gap affects your specific question.

Freshness and drift

When was this collected? Has the underlying process changed since? Set an explicit expiry expectation rather than assuming data is timeless.

Definitions and units

Confirm what each column actually means. “Active user,” “revenue,” and “resolved ticket” are defined differently across teams — mismatched definitions silently corrupt joins and comparisons.

Missingness

Quantify missing values per field and ask why they are missing. Decide deliberately whether to drop, impute, or model the absence as a signal.

Distribution sanity

Plot the distribution, not just the mean. Check ranges, look for impossible values, spikes at defaults, and suspicious round numbers that hint at manual entry.

Leakage and confounds

Ensure no field secretly encodes the answer you are trying to predict, and note variables that move together for reasons outside your model.

Why this belongs in computational thinking

Abstraction — a core CT pillar — is exactly the act of deciding what to keep and what to discard. Data thinking is abstraction applied to evidence: choosing which measurements represent the phenomenon faithfully, and being honest about what the abstraction throws away. Get this wrong and every downstream algorithm, however elegant, computes a precise answer to the wrong question.

References