There are nulls in the report. You ask how to handle them.
You get a good answer. Coalesce them, or filter them, or flag them for review, with a sensible discussion of which is appropriate when. You pick one, ship it, and the report looks correct again.
Two days later somebody notices the totals are down about 3% against last quarter, and you find the actual problem. A key upstream changed format, so a join that used to match stopped matching, and it has been quietly producing nulls for six weeks. Your fix hid it.
🔍 The question you asked was answerable
Nothing went wrong in that exchange, which is what makes it hard to catch.
You asked a well-formed question about null handling and got a well-formed answer about null handling. There was nothing in your question suggesting the nulls were new, or unexpected, or concentrated in rows that used to match something. So the answer treated them as a normal data condition to be handled, which is what they usually are.
A person looking over your shoulder might have asked "were they always there?" A prompt has no way to ask that unless you have made it possible.
Two versions of this show up constantly in data work, and they are different failures worth telling apart.
Nulls that are new. A join key gains trailing whitespace, or changes case, or gets cast to a different type upstream. A LEFT JOIN that used to match now does not, and unmatched rows come through as nulls. The symptom is nulls. The cause is a key format change three steps back.
Numbers that are slightly off. A join that was one-to-one becomes one-to-many, so rows get duplicated. Counts inflate and averages move toward whatever the duplicated rows contain. The symptom is a metric that looks wrong by a few percent. The cause is a join that fans out.
In both cases you can ask a reasonable question about the symptom and get a reasonable answer that leaves the cause running.
🧠 Why this happens early in a career
There is well-established research here, and it is not about programming.
In 1981, Chi, Feltovich and Glaser asked physics students and physics professors to sort problems into groups. The students grouped them by what the problems looked like: the ones with pulleys together, the ones with inclined planes together. The professors grouped them by the principle needed to solve them, so a pulley problem and a ramp problem sat together because both were about conservation of momentum. The finding has been replicated enough to be widely accepted, and the same literature notes that novices depend more on visible clues than experts do.
That is this problem exactly. Nulls in a report are the pulley. The join behaviour is the principle.
It is not that beginners are careless about where they look. It is that the visible thing is genuinely the only thing available to organise a question around, until you have enough experience for the deeper structure to be visible at all. An experienced engineer sees "nulls appearing in a column that used to be populated" and thinks join, because they have been caught by that before and it filed itself under something.
Which means the advice "look for the root cause" is not usable. If you could see the root cause you would already be asking about it. What you need is a way of writing the question that opens the path to it without requiring you to know the answer first.
✅ Write the gap before you ask anything
Two lines, before the question:
Expected: every order row has a matching customer name
Actual: about 4% of rows have a null customer name, starting some time this month
That is the whole technique. Write what you expected. Write what you got. Then ask.
Notice what happened just by writing it. "There are nulls" is a state. "Rows that should have matched are not matching, and this is new" is a change, and a change has a cause. The second version cannot be answered with "here is how to handle nulls," because it is no longer a question about nulls.
Three things make it work:
Expected is where the information is. You are stating what the system is supposed to do, which is knowledge nobody else has. That single line rules out most of the wrong answers.
"Starting this month" turns a state into an event. Anything with a start date has something that changed. That is the most useful thing you can say, and it is the thing people leave out most.
A percentage beats "some." Four percent of rows suggests a subset that shares a property. Ninety percent suggests something structural. Those lead in different directions.
You do not need to know the cause to write these two lines. That is the point of them.
⚖️ The objection worth taking seriously
The weak version is "I do not know where the cause is, which is why I am asking." Fine, and the two lines do not ask you to know.
The stronger objection is this: in a lot of data work you do not know what to expect either. You are looking at a metric you do not own, in a pipeline someone built before you arrived, and the honest state is that you have no idea what the correct number is. "What should this be?" is the actual question. The expected-versus-actual framing assumes you hold one half of a comparison, and often you do not.
That is a real limitation and it applies more often than I would like. When you genuinely do not know what to expect, this technique does not help you, and pretending to an expectation you do not have is worse than saying nothing.
What it changes is what you should do first. If you cannot write the expected line, then establishing the expectation is the task, and it is a different one from fixing the symptom. Find who owns the metric. Find what it looked like six months ago. Find whether anyone has ever validated it. Those are unglamorous and they are the actual work, and no amount of prompting substitutes for them.
The technique is for the common case where you do have a violated expectation and have not written it down. That covers most bug reports. It does not cover exploration, and it is worth knowing which one you are in before you start.
🎯 The takeaway
Two lines, before the question:
Expected: [what the system is supposed to do]
Actual: [what it is doing, with a rough size and a rough start date]
1. Expected is the line only you can write. It carries the knowledge that rules out wrong answers.
2. Say when it started. A state invites handling. A change invites investigation.
3. Give a rough proportion. Four percent and ninety percent point in different directions.
If you cannot write the expected line, that is useful information too. It means the job is not fixing this yet. It is finding out what the number is supposed to be.
