Priya had been a data engineer for three years when she shipped a transformation that quietly dropped every order from one region for six days. Nothing crashed. The job went green. A finance analyst noticed the totals looked thin, and by then three reports had gone to leadership. Priya had reread her own SQL twice before merging, and she still had not seen the filter she had left in from testing. That week she started pairing with a teammate named Rohan, and this FAQ collects the questions people asked her afterwards about pairing on DataOps work.<\/p>\n
Because she wrote it. When you build a pipeline step by step, your brain stores each step as done and correct. Rereading gives you the comfort of familiarity, not a fresh look. The leftover filter sat on a line she had typed herself, and her eyes read it as part of the plan.<\/p>\n
Rohan, who had never seen the query, asked a naive question within two minutes: “Why is there a region equals value in a script that is supposed to cover everyone?” It was the sort of question that only an outsider thinks to ask. That is the whole case for a second pair of eyes in one example.<\/p>\n
It is simpler than it sounds. Two people look at the same change before it is merged. One explains, one questions. Sometimes they sit together and share a screen; sometimes the reviewer reads the pull request alone and leaves comments. Priya and Rohan tried both and settled on a rhythm: a short live walkthrough for anything touching shared tables, and written review for small fixes.<\/p>\n
The reviewer’s checklist came together naturally over a few weeks:<\/p>\n
No, and Priya was careful to say so. Tests catch what you thought to test. A person catches what you did not think to ask. The two cover different ground, and the best results come from both. If you want a grounding in the automated side, the piece on a hands-on start with automated checks for data workflows<\/a> is a good companion to this one.<\/p>\n Rohan even suggested a habit that tied the two together: whenever a review found a problem, they wrote a test for it before fixing it. Over a quarter their suite grew with every catch, so a mistake found once could not return unnoticed.<\/p>\n Rohan’s trick was to read the change as if explaining it to a new hire. He started with the output: what should the table look like afterwards? Then he read the logic backwards from that expectation. Models built in dbt make this easier because each step is small and named. Priya’s team leaned on a guide to shaping raw tables into clean models with dbt<\/a> when onboarding new reviewers, since the habit of small, readable steps makes a second reader’s job lighter.<\/p>\n This worried Priya at first. Rohan had his own work, and she did not want to become a bottleneck. They agreed on two rules. First, changes stay small, so a review takes minutes rather than hours. Second, reviews run both ways, so the time spent evens out over the month. She also learned to include a three-line note with every request: what changed, why, and what she was least sure about. That note cut his reading time roughly in half, by her estimate, and it sharpened her own thinking before he even looked.<\/p>\n Priya’s rule of thumb became fifteen to thirty minutes. If a change needs more than that, it is usually too big, and the better fix is to split it. Rohan also learned to stop reading at the first real concern, send the comment, and let Priya respond, instead of collecting a huge list before saying anything. Short loops kept both of them in context and kept goodwill high, which mattered more than any process document. A review that drags for days teaches people to avoid asking.<\/p>\n Not always the most senior person. Priya’s best catches came from an analyst who knew the business numbers by heart and could smell a wrong total at a glance. Pairing a data engineer with an analyst turned out to be among the most productive combinations, because each noticed what the other took for granted. Watching the dashboards afterwards is part of the same loop; the beginner-friendly look at watching data pipelines after release<\/a> explains what to look at once the change is live.<\/p>\nHow do you review transformation code you did not write?<\/h2>\n
What if the reviewer is slower than the author?<\/h2>\n
How long should a review take?<\/h2>\n
Who should be paired with whom?<\/h2>\n
Does this only matter for code?<\/h2>\n