What Am I Actually Measuring?
One thing that’s becoming increasingly clear during my internship is that understanding the problem is far harder than building the solution.
I started working with a street-audit dataset that, honestly, was a nightmare to understand.
At first, I thought the challenge would be cleaning the data and figuring out how to visualize it. Build a dashboard, put things on a map, create some scores, derive some insights. It seemed straightforward enough.
But I kept hitting deadlocks.
Every time I thought I understood something, I realized I was missing context. What did this observation actually mean? Why was it collected? What was the person collecting it looking for? Two observations might look similar in a spreadsheet but represent completely different realities on the street.
I realized I was trying to understand the data without understanding how the data came into existence.
So I stopped looking at the data itself and started looking at the process that generated it.
That was probably the biggest breakthrough I had.
The moment I understood how the audit was conducted, a lot of things started making sense. Categories made sense. Relationships made sense. Even some of the gaps in the data started making sense.
And it made me realize something I hadn’t thought much about before.
Data isn’t reality. It’s someone’s attempt to represent reality.
That distinction sounds small, but I think it’s huge.
Most of the time, we treat datasets as if they’re objective descriptions of the world. But every dataset is shaped by choices. Someone decided what was worth observing, how it should be categorized, what should be measured, and what should be ignored.
The data wasn’t the city.
The data was a lens through which the city was being viewed.
The more I worked on the project, the more I realized I wasn’t actually building a dashboard.
The dashboard is just a screen.
The interesting question is what the screen is trying to represent.
Initially, I was looking at the dataset as a collection of street-level observations: footpaths, potholes, waste, streetlights, public assets, accessibility issues, and environmental conditions.
But the deeper I went, the more I started seeing multiple layers.
At one level, this could help citizens understand the quality of the places they interact with every day.
At another level, it could help municipalities identify where resources and interventions are needed most.
At another level entirely, it could become a way of understanding whether public spaces are actually improving over time.
What started as points on a map slowly started looking like a model of how a city functions — or doesn’t function.
And that shift changed how I thought about the project.
Around the same time, I had another realization about AI.
Historically, I’ve used AI as an advisor. I’d ask it for ideas, frameworks, and suggestions, then go do all the implementation myself.
My mentor challenged me on that.
Instead of asking AI what I should do, why not let it do some of the work?
Why not let it generate prototypes, explore different approaches, handle the repetitive parts, and get me to a first draft faster?
Then I could focus on evaluating the output, refining it, and deciding which direction was worth pursuing.
Once I started approaching it that way, things moved much faster.
Get Srihari’s stories in your inbox
Join Medium for free to get updates from this writer.
Not because AI was producing perfect outputs, but because it dramatically reduced the cost of exploration.
I could investigate multiple directions before committing to one.
Ironically, as implementation became easier, it became even more obvious where the real bottleneck was.
Understanding.
Understanding what the data represented.
Understanding the environment it came from.
Understanding the assumptions embedded within it.
Understanding what was worth measuring in the first place.
The more I worked on this project, the more convinced I became that the challenge wasn’t building a dashboard.
The challenge was deciding what the dashboard should represent.
I’m still not sure I have the perfect answer.
But I think I’m getting closer.
Initially, I thought I was mapping potholes, drains, trees, streetlights, accessibility issues, and public assets.
Now I think those things are simply signals.
Individually, they don’t tell us very much.
Together, they tell a story about the condition of a place.
They tell us something about the quality of the public environment people experience every day.
Whether a street feels accessible.
Whether it feels maintained.
Whether it feels neglected.
Whether public infrastructure is functioning as intended.
Whether the environment supports the people who use it.
What started as a collection of observations began to feel more like an attempt to understand the lived experience of a place.
And that’s why the question in the title has stayed with me.
What am I actually measuring?
Today, my best answer is this:
I’m not measuring potholes.
I’m not measuring streetlights.
I’m not measuring drains.
I’m measuring the condition of a place through the signals those observations provide.
Maybe that answer will change as the project evolves.
But for now, that’s the most interesting thing I’ve learned.
What began as a data-cleaning exercise turned into a question about representation, measurement, and reality.
And those questions are far more interesting than the dashboard I originally set out to build.
