🗣️ Language Is the First Bug
Field Notes on Perception
This is part 5 in the Field Notes on Perception series, where I’m exploring how we see structure—inside data systems, inside organizations, and inside ourselves. This one’s about language: how the words we use shape what we build, how we think, and why so many of us feel like we’re doing the wrong job with the right title.
There’s something I’ve come to believe after years of working in data and systems:
The hardest problems aren’t technical. They’re linguistic.
We call people “engineers” who aren’t engineering.
We use the word “governance” when we mean “access control.”
We say “platform” when we mean “a bunch of tools glued together.”
We say “insight” when we mean “a chart someone made that confirms what we already wanted to do.”
Our words are broken. Or worse: they’re reversed.
And that reversal is wrecking our ability to think clearly about what we’re doing.
🎭 Titles That Mislead Us
Take “Data Engineer.”
Sounds solid, right? Grounded. Repeatable. A known craft. But let’s be honest: most great data people I know aren’t engineers. They’re artists in exile. They improvise. They collage half-baked systems into something usable. They find aesthetic harmony between source systems that don’t want to talk to each other. They write five layers of abstraction around an ugly business rule just to make it vaguely operable by Tuesday.
That’s not engineering. That’s interpretive dance inside a maze made of databases and spreadsheets.
So what should we call them? Depends on the work.
A classically trained engineer doing data work might actually be a Data Infrastructure Engineer
A toolsmith who builds internal frameworks and abstractions might be a Data Platform Architect
A pipeline wrangler making broken systems legible might be a Semantic Mediator
A business-aware technologist making messy data make sense might just be a Data Translator
And the ones who can do all of the above? Maybe Information Artist isn’t such a stretch after all.
But of course—we can’t actually call them these things.
The market demands consistency. HR systems need standardized titles. Salary bands depend on clean mappings. Internal mobility requires interchangeable labels. So we pick a term—Data Engineer—and let it absorb everything.
And just like that, the model becomes the thing.
The language flattens the craft.
And the deeper the expertise, the harder it is to describe.
And in this case, we decided to call it engineering, but we’re not even working with engineering conditions. Classic engineering looks like this:
Take a battery. Make it last 10% longer.
Reduce the weight by 8%.
Maintain performance in a broader temperature band.
Document the materials. Certify it for safety. Ship it at scale.
Clear spec. Clear constraints. Clear materials. Clear physics.
But most data work? It’s doing something no one has done before with constraints no one will admit exist—using tools that were meant for something else entirely.
And still—still—we use language that implies stability. Repeatability. Optimization. Control. That language is a lie. And it costs us everything.
🧠 Why does this matter?
Because the moment you call a person a “data engineer” (treating the model as the thing), you start evaluating that person by the wrong metrics.
You think they should care more about performance than meaning.
You assume their job is to build repeatable pipelines, not interpret fractured worlds.
You forget that their real value isn’t syntax—it’s judgment.
Words shape expectations. Expectations shape systems. And systems—over time—shape people.
🧩 Same Words, Different Worlds
We assume language brings us closer together. But in practice? It often does the opposite.
Because by the time we say “data pipeline” or “active user” or “real-time,” we’ve each already filled those words with our own assumptions.
To the business team, “real-time” might mean seconds. To the data team, it might mean yesterday.
To product, “active user” means engagement. To finance, it means billing status. To marketing, it means “someone we can still email.”
So we nod along. We move fast and break things. And we mistake agreement on words for agreement on meaning.
Our language has degraded—not because we stopped talking,
but because we stopped noticing how differently we hear the same words.
🌀 The Spiral of Simplified Language
As the world gets more complex, our language evolves to keep up. But not always in the way we think.
We don’t name the complexity—we abstract it. We compress it. We give it a shiny acronym and move on.
A complicated product backlog becomes "the roadmap."
A fragile ML pipeline becomes "the AI."
A desperate rewrite becomes "the platform migration."
A swirling mess of incentives and interdependencies becomes "a metric."
And soon, we’re not talking about the thing anymore. We’re talking about the representation of the thing. Then the representation of that. Until we forget there was a thing at all.
📆 When Language Fails, We Default to Deadlines
When teams can’t align on meaning, they align on dates. We don’t always agree on the requirements. We’re fuzzy on scope. Ownership is ambiguous. Dependencies are in flux. But the one thing everyone can agree on?
A date.
“Let’s just ship it by Friday.”
“Let’s target Q3.”
“Let’s get something out this month.”
And suddenly, a deadline becomes the decision. Not the outcome. Not the insight. Not the value. Just the timestamp.
Because when language breaks down, time is all we have left to coordinate with.
But deadlines don’t clarify anything. They just force movement.
And pressure without clarity doesn’t create alignment. It creates burnout.
So we grind. We over-engineer. We throw more tools and dashboards at the fog. But what we actually need is a way to talk about what we’re building—together.
🗣️ When Meetings Become Theater
When teams can't agree on meaning, they perform alignment instead.
That’s what most meetings become—a shared ritual where people nod along using the same words with different definitions.
The chart gets shown.
The roadmap gets updated.
The initiative gets “aligned.”
But underneath it all—very little understanding has been exchanged.
This isn’t always bad. Performative meetings can still serve a purpose. They create a sense of momentum. They offer psychological safety. They reinforce team bonds. But they shouldn’t be the end state.
If language is the bug, then the goal of the meeting shouldn't be performance. It should be improving the signal over time.
And that only happens when we start speaking in metadata:
Not just "we’re on track"—but "we hit 4 of 6 milestones; 2 are blocked, here’s why"
Not just "the data looks off"—but "the source table changed 3 days ago; the lineage hasn’t updated"
Not just "it's high priority"—but "three execs have asked for it this week, and it blocks two downstream teams"
Metadata isn’t just for systems. It’s how teams debug their own communication.
♻️ So what would it look like to start telling the truth?
Maybe we’d say:
“This is not a data pipeline. This is a working theory of a fractured process, made legible for now.”
“This dashboard is not a report. It’s a conversation starter.”
“This isn’t governance. It’s guesswork plus risk tolerance dressed up in SharePoint.”
“The data quality is better than it was last week, but it’s still not perfect - tread carefully”
“We didn’t build a platform. We built a system we hope we don’t have to rebuild for 12 months.”
That kind of honesty takes guts. But it clears space to do the real work. It’s not a magic fix. But it gives people something to stand on. And they should demand it.
🪞 Speaking in Metadata
The only way to make meaning real is to show your work.
When someone says “real-time,” you should see a timestamp.
When someone says “trusted,” you should see the lineage.
When someone says “high quality,” you should see the thresholds—and the last time they failed.
Metadata isn’t just how we speak clearly. It’s how we earn clarity together.
But here’s the thing: You can’t speak in metadata if you’re not collecting it. And you can’t build a culture that values traceability if there’s nothing to trace.
That’s why in Metadata First, I argued that metadata isn’t exhaust—it’s architecture.
Not an afterthought, but a foundation.
🌀 Metadata First
This is part 4 in the Field Notes on Perception series, where I’m exploring how we see structure—inside data systems, inside organizations, and inside ourselves. This one’s about the moment when the word “metadata” makes everything feel too complicated—and why that feeling isn’t failure, but invitation. If you’re new here, Part 1 is
Only when you start collecting it proactively and on purpose can it start to seep into your language, your expectations, and your culture.
🧠 The Real Work
Our job isn’t to engineer data. The job is to render the invisible visible in ways that hold up long enough for decisions to be made and risks to be taken. That requires structure, judgement and using language we actually mean.
Not engineering, in the classical sense. Something messier. More human. Closer to interpretation than implementation. Closer to art than automation.
And maybe—just maybe—our teams would feel a little less broken if we admitted that.
Here’s a challenge:
Try speaking in metadata today.
Don’t say “real-time”—say “updated every 18 hours.”
Don’t say “clean”—say “4% missing value, last checked April 2nd.”
See what changes.
Happy Wednesday!
Zac
@cmdrvl
https://cmdrvl.com
Field Notes on Perception is an ongoing series about how we see—systems, data, patterns, and the invisible structures that shape how we think and build. It’s a personal lens on trust, clarity, and cognition in a noisy world. Part 4 is Metadata First, Part 3 is Why I Voted for Command Reveal, Part 2 is Seeing Structure, and Part 1 is All Code Is Pressure.