A data pipeline change that only its author has examined is an unverified claim. DataOps pair review is the discipline of asking a second engineer to test that claim before consumers downstream inherit the result. This how-to lays out a repeatable sequence you can adopt for transformations, schema edits and scheduling changes, and each step comes with its reasoning, which lets you bend the routine around your own tooling.

Why the author is the weakest checker

When you write a transformation, you hold a mental model of the data: which columns are populated, which keys are unique, which timestamps are in which zone. Your tests, if you wrote them, encode that same model. They pass because they were built by the same head that built the code. A reviewer arrives with a different model, or none at all, and the gaps between the two are exactly where defects hide.

Think of it as measurement error. If one instrument is used to calibrate itself, its bias never shows up. Two independent instruments disagreeing is the signal you want, and in pipeline work the second instrument is a person who has not seen your assumptions.

Step 1: Shrink the change until it can be reviewed

Review quality falls off sharply as the diff grows. Aim for a change a colleague can absorb in fifteen minutes. If a single request mixes a column rename, a join rewrite and a new schedule, split it into three. Smaller changes also make it obvious which edit caused trouble when something breaks.

A practical test of size: if the author cannot summarise the change in one breath, the reviewer will not be able to hold it in their head either. Treat that as a cue to cut.

Step 2: Write the intent in plain sentences

Before anyone opens the code, the author states what the change should do and what should stay the same. Two or three sentences are enough: “Daily orders now include refunds as negative rows. Row counts for non-refund orders must not move.” This statement becomes the reviewer’s yardstick. If the code and the sentences disagree, you have already found something worth discussing.

Step 3: Hand over a sample, not just code

Give the reviewer a small, real extract: a few hundred rows that include the awkward cases such as nulls, duplicates, late-arriving records and the oddly formatted legacy entries every dataset carries. Reading logic is useful, but watching it act on messy rows is better. Ask the reviewer to predict the output for three rows by hand before running anything. Mismatched predictions expose misunderstandings faster than any linter.

Step 4: Let the reviewer drive the checks

Resist the urge to narrate. The reviewer chooses what to probe and the author only answers questions. Typical probes include:

• Row counts before and after each stage, to spot silent fan-out from a join.
• Distinct counts on keys that are supposed to be unique.
• Minimum and maximum dates, to catch timezone shifts and truncated loads.
• The share of nulls in each new or touched column compared with the previous run.
• One manual trace of a single record from source to final table.

Record the answers in the change request. A review with no written evidence is a conversation, not a check.

While probing, keep a short log of surprises, even ones that turn out to be harmless. A surprise that is explained today becomes documentation for whoever meets the same oddity in six months. Surprises that cannot be explained become the first items on the fix list.

Step 5: Review the failure path, not only the happy path

Ask three things about failure. What happens if the upstream file is late? What happens if the job runs twice? What happens if half of it fails? Idempotency, retry behaviour and partial writes are rarely covered by the author’s own tests because they are boring to imagine. A reviewer with no emotional investment in the design will happily imagine them.

Step 6: Check who and what is downstream

Pipelines rarely fail in the pipeline. They fail in the dashboard, the export, the model that quietly retrains on altered data. Have the reviewer name at least two consumers of the table and ask whether those consumers were told. A short message to the owners of those consumers, sent before the merge, costs almost nothing.

Add a final question to your template: “What did you assume that I could not have known?” Authors are often surprised by their own answer, and the answer tends to point straight at a missing test or an undocumented rule about the source system.

Step 7: Close the loop and return the favour

Once the change ships, the author tells the reviewer what happened in the first run, including anything the review missed. That feedback is how the pair improves. Then the roles reverse: the next change comes from the reviewer, and the former author examines it with the same care. Reciprocity keeps the habit from feeling like an audit.

What the numbers tell you after a month

Do not guess whether pairing is worth it; measure it lightly. Keep a tally of three things: the number of reviews, the number that surfaced a real defect, and the number of production incidents traced to an unreviewed change. Over a month or two the pattern is usually clear without any statistics beyond a simple count. If reviews find little, your changes may be safe enough to review sampled rather than universally. If incidents cluster around unreviewed edits, the case makes itself.

Be careful with one trap. If defect catches drop to zero, that does not prove the process is wasteful; it may mean reviewers have grown lenient. Seed an occasional deliberate flaw in a practice change and see whether it is spotted. That is a fair test of attentiveness.

A parallel from outside the warehouse

The same logic applies to any human data-entry task. People researching treatment abroad often meet KneeHospitals, a medical tourism website whose directories run country by country through hospitals and doctors, with request forms for price quotes and appointments sitting alongside. Without commenting on any provider, the data lesson is plain: a mistyped date or passport spelling on such a form is a defect no one will catch unless a friend or relative reads it against the original document. Inputs deserve a second reader whether they enter a warehouse or an enquiry form.

Where to go next

If you want background on why pipelines fail in the first place, this account of keeping live analytics flowing when jobs break provides useful context. Teams working across several providers may also find the overview of running data operations across many clouds relevant, since review habits need to travel with the work. A real-world story of a manufacturer reclaiming hours of daily effort through disciplined data work shows what steady practice can add up to.

Summary checklist

1. Keep the change small enough for a fifteen-minute read.
2. State intent and invariants in plain sentences.
3. Supply a sample with awkward rows.
4. Let the reviewer choose the probes and write down results.
5. Examine failure, rerun and partial-write behaviour.
6. Name downstream consumers and tell them.
7. Report back after the first run and swap roles next time.