Most of my data work does not feel like math.

It feels like translation.

Someone asks a question in normal human language. The database answers in tables, fields, codes, dates, joins, and the occasional value that looks like it was named during an emergency.

Somewhere between those two things, there is usually a definition hiding under a rock.

That is where the work actually happens.

Not in the chart. Not in the dashboard. Not even in the query, though the query is where the evidence eventually has to show up and defend itself. The real work is taking a human question, translating it into something the data can answer, and then translating the answer back into something a person can use without accidentally lying to themselves.

Which is easier said than done.

As usual.

The question is never just the question

People ask data questions the way people ask most questions: reasonably, casually, and with a lot of context left unsaid.

Someone asks:

How many applicants do we have?

That sounds like a normal question. It is, in fact, a trap.

Do we mean people or applications? Submitted applications or started applications? First-year only? Graduate? Transfer? This year? This term? As of today? As of the same date last year? Are withdrawn applications included? What about deferrals? What about duplicate applications? What about someone who applied to both campuses? What about someone who applied, cancelled, returned, deposited, cancelled again, and is now somehow still appearing in three reports like a ghost with a Slate record?

The question sounded simple for about four seconds.

Then it became reporting.

The database cannot answer “How many applicants do we have?” because the database does not know what we mean by “applicant.” It knows records. It knows dates. It knows codes. It knows that some field has a value and another field does not. It knows exactly what is there and absolutely nothing about what we intended.

So the first job is translation.

The human question has to become something like:

Count distinct people
with a submitted application
for the selected application year
excluding specific decision codes
as of the reporting cutoff date.

That is a much uglier sentence.

It is also a much more honest one.

Databases are literal little goblins

I like databases.

I also believe they are, spiritually, goblins.

They are very good at guarding treasure. They are very bad at understanding why you want it. They will do exactly what you ask, not what you meant, and then sit there quietly while you present the wrong number in a meeting.

This is not the database's fault.

It is just literal.

That is part of why I like SQL. SQL forces you to say the thing out loud. You have to pick the table. You have to decide how the tables relate. You have to define the filter. You have to choose the date. You have to decide whether you are counting rows, applications, people, decisions, deposits, or some unholy combination of the above.

A lot of reporting mistakes live in the places where language lets us be vague.

SQL is less forgiving.

Not perfectly honest, of course. You can absolutely write misleading SQL. The machine will not stop you. It has other things to do, apparently. But SQL does make the assumptions visible in a way that normal conversation often does not.

That visibility matters.

Because once the logic is visible, you can argue with it.

And arguing with the logic is much better than arguing with a number.

Words are not as stable as they look

A lot of confusion in reporting comes from words that sound obvious.

“Applicant.”

“Admit.”

“Deposit.”

“Enrolled.”

These are normal words. They seem like they should mean normal things.

They do not always behave that way.

In a reporting context, a word like “deposit” might mean:

  • anyone who has ever paid a deposit
  • anyone who paid a deposit and has not cancelled
  • deposits received by a specific date
  • net deposits after excluding certain decision codes
  • deposited applications
  • deposited people
  • deposits by campus
  • deposits by student type
  • deposits by application round
  • deposits according to the report someone made in 2019 and everyone still trusts because no one wants to open it

All of these may be reasonable.

They are not all the same.

This is why data work starts to feel less like arithmetic and more like reading an old text with three possible translations and a footnote that says “meaning uncertain.”

The word is not enough. The definition is the thing.

Reports can hide the translation

A finished report can look very official.

It has a title. It has filters. It has totals. It may even have a chart, and charts have a strange way of making people feel like a decision has already been made.

But the report is not the translation.

The translation happened earlier, before the chart showed up dressed for work.

It happened when someone decided what counted. It happened when someone chose the cutoff date. It happened when someone excluded a decision code, joined to a status table, grouped by application year, or decided that this report counts people while that other report counts applications.

The report is the visible part.

The logic is the skeleton.

And when the skeleton is weird, the report may still stand up, but you probably should not trust it to walk very far.

This is one reason I care so much about definitions, notes, and transparent assumptions. Not because I enjoy making documentation for its own sake. I am not a monster. I care because reports outlive the conversations that created them.

Someone makes a report for a very specific purpose. Then someone else finds it useful. Then it becomes familiar. Then it becomes official. Then, one day, a person opens it and asks why the fall applicant count excludes something that appears in the spring report, and everyone looks around like the answer might be hiding under the conference table.

This is how reports become haunted.

Documentation is basically ghost prevention.

“Are we up?” is not a database question

One of the most common human questions in enrollment work is some version of:

Are we up this year?

That is a good question. It is also not yet a data question.

Up compared to what? Last year on the same calendar date? Last year at the same point in the admissions cycle? Final numbers? Budget? Goal? Applications? Admits? Deposits? Net deposits? Enrolled students? Which campus? Which population? Which exclusions?

The human meaning is clear enough: people want to know whether things are going well.

The data meaning is not clear enough yet.

That gap is where translation lives.

The database is not going to answer “Are we up?” It can answer something more precise, like:

select count(distinct person_id)
from application
where submitted_date is not null
  and application_year = 2026;

But even that is only part of the answer.

Maybe the count needs a year-over-year cutoff. Maybe it needs to exclude certain rounds. Maybe it needs to count only primary applications. Maybe it needs to separate domestic and international students. Maybe it needs to be explained next to a note saying the inquiry form changed last year, so comparison is possible but slightly cursed.

The SQL can count.

It cannot decide what comparison is fair.

That part still requires judgment.

The danger of technically correct answers

One of the more annoying things about data work is that an answer can be technically correct and still not be useful.

Worse, it can be technically correct and actively misleading.

The query runs. The number appears. The chart renders. The dashboard loads. No error messages. Everyone breathes a sigh of relief.

And yet the number may be answering a different question from the one people thought they asked.

This is why “the query works” is not the same as “the report is right.”

That was a painful lesson to learn, because getting the query to work feels like victory. And sometimes it is. There are queries that deserve a small parade when they finally run.

But a working query is only one checkpoint.

The better questions come after:

Does this count the right thing?
Does this exclude the right cases?
Does this match the business process?
Does this line up with how people will interpret it?
Would someone reasonably misunderstand this number?

That last question matters more than people think.

A report does not just have to be accurate in the technical sense. It has to be resistant to the most likely misunderstanding.

Which is a very annoying standard.

Unfortunately, it is also a useful one.

Data work is also memory work

Another thing I did not appreciate at first is how much reporting depends on institutional memory.

Why does this code mean that? Why do we exclude this population? Why does this report use the released date instead of the created date? Why does this field have three values that all seem to mean “cancelled,” except one of them apparently does not count because of something that happened before I worked here?

Some of those answers are in documentation.

Some are in old emails.

Some are in someone’s head.

Some have been lost to time, which is rude.

This makes data work partly archaeological. You are not just querying the current database. You are digging through old decisions that have hardened into structure.

A field name might reflect an old process. A code might have survived a system migration. A report might include a filter because of a one-time exception that became permanent through the power of nobody remembering why it was there.

This is another kind of translation: translating between the system as it exists now and the history that made it that way.

Sometimes the answer is not “because the data says so.”

Sometimes the answer is “because five years ago someone needed a workaround, and now the workaround has a desk.”

Good definitions are a kindness

This may sound dramatic, but I think a good definition is a form of kindness.

It is kind to the person using the report.

It is kind to the person maintaining the report.

It is kind to the future version of yourself who will absolutely not remember why you wrote that case statement unless you leave a note.

A good definition says:

This is what this number means.
This is what it does not mean.
This is when it was counted.
This is what changed.
This is what you should not assume.

That does not make the work flashy. No one throws a party because a metric has a clear definition. There are no balloons for “consistent cutoff logic.”

But clear definitions are one of the main things separating a useful report from a colorful rumor.

And honestly, there are enough colorful rumors.

Tools are not the hard part

I like tools. I like SQL. I like Python. I like dashboards when they are useful and not just decorative. I like databases because they impose structure on things that would otherwise live forever in someone’s inbox as an Excel attachment named something like:

final_final_revised_USE_THIS_ONE_v3.xlsx

A file name like that is not a file name. It is a cry for help.

Tools matter.

But tools do not solve the translation problem by themselves.

A dashboard can make a bad definition look official.

A Python script can automate a mistake at impressive speed.

A database view can hide logic so well that everyone forgets it exists.

A chart can make a questionable comparison look like insight because the bars are aligned nicely and the colors are tasteful.

The tool is only as good as the thinking behind it.

That is not a very exciting sentence, but unfortunately it keeps being true.

The liberal arts part sneaks in

I think this is why data work still feels connected to a liberal arts way of thinking for me.

At its best, data work is not just technical production. It is interpretation.

You are asking what words mean. You are checking assumptions. You are comparing claims. You are noticing ambiguity. You are trying to understand how a thing came to be represented the way it is.

That is not separate from the technical work.

It is part of it.

A query is not just a query. It is an argument about what should count.

A dashboard is not just a dashboard. It is a way of arranging attention.

A metric is not just a metric. It is a definition with consequences.

That does not mean every report needs to become a seminar. Please, no. Some reports just need to tell someone how many people registered for an event.

But even then, someone has to decide what “registered” means.

There is always a translation.

Final thought

Data work is often described as technical work, and it is.

But the technical part is only one layer.

Underneath it is language. Definitions. Memory. Context. Judgment. The annoying but necessary habit of asking, “What do we actually mean by that?”

That question can feel slow. It can feel pedantic. It can make a simple request take longer than everyone hoped.

But it is usually where the useful work begins.

Because the number is not the answer.

The answer is the translation that lets the number mean something.

ἀρχὴ σοφίας ὀνομάτων ἐπίσκεψις
“The beginning of wisdom is the examination of names.”
— Antisthenes