DEV Community: Brian Cariveau

She had a PhD from MIT. She quit after 6 months because nobody knew what sls_txn_f47 meant.

Brian Cariveau — Sun, 22 Feb 2026 12:59:00 +0000

Dr. Jennifer Park walked into my office on her last day.

"I'm sorry," she said. "I really wanted this to work."

I'd recruited her personally. PhD in Machine Learning from MIT. Five years at Spotify building recommendation engines. Above-market salary. Equity. The works.

She lasted six months and four days.

"What happened?"

"I spent six months trying to do one thing: build a recommendation engine. At Spotify, I built similar systems in six weeks."

"And here?"

"Here, I spent six months just trying to understand the data."

She opened our Snowflake warehouse. 847 tables.

sls_txn_f47

usr_bhv_ag_01

car_lst_vw_2

bid_hist_tmp

"Nobody knows what these mean," she said. "The engineer who built them left two years ago. I spent three months reverse-engineering the schema. Then I discovered we have seven different definitions of user_id across tables. Seven."

"I'm not a bad data scientist," she said. "Your data is just impossible to work with."

Four months later

We hired Alex.

Same challenge: "Build a recommendation engine."

He understood the data model in 15 minutes.

Had a working prototype by end of day.

Shipped an upgraded version the next week. Clickthrough rate up 18%.

What changed?

We rebuilt the foundation.

Killed 535 zombie tables nobody was querying.

Renamed everything:

sls_txn_f47 → auction_transactions
usr_bhv_ag_01 → user_behavior_daily
car_lst_vw_2 → car_listings_current

Created one source of truth for every entity.

Documented everything.

Asked "Is this stupidly simple yet?" until the answer was yes.

The test:

Old model: 30 minutes to find last month's revenue

New model: 30 seconds

Alex understood the structure in 15 minutes because the naming was self-explanatory. Actually building the recommendation engine took the rest of the day.

But he wasn't stuck for weeks reverse-engineering cryptic schemas like Jennifer was.

The lesson

You can't build on top of chaos.

Jennifer was brilliant. The data was just impossible to work with.

How many great engineers have you lost because your schema looked like tbl_usr_tmp_20220304?

This is a scene from The Auction Block — a business fable I wrote about what data/analytics teams get wrong (and how to fix it). Think The Phoenix Project but for data & AI teams. I promise you will become a better version of yourself if you thumb through it!

If you've ever inherited a data graveyard and had to rebuild it, you might find it useful.

Available on Kindle & paperback - https://www.amazon.com/Auction-Block-Novel-About-Teams-ebook/dp/B0GM8BRVWC

We're Manufacturing Dashboards & Data Nobody Uses (And the Data Proves It)

Brian Cariveau — Thu, 15 Jan 2026 05:31:35 +0000

I ran usage analytics on our dashboards.

(I like to call it "Analytics on ourselves"—actually paying attention to what we build.)

Result: 60%+ hadn't been touched in 90 days.

Run the same analytics at the data level and the picture is usually uglier!

The Retail Analogy

If a product sat on an end cap at Target for 90 days without selling, how long would we keep it there?

Zero days. Pull it immediately. Run a promotion or discontinue it.

But in analytics and data? We just keep building more.

47 dashboards. 28 unused. But we're planning three more this quarter.

1,000s. or 10,000s. or 100,000s+ of tables and views. 70% plus never used. But we are adding 500 more in the next week.

The Manufacturing Problem

In my last post, I talked about viewing analytics as a manufacturing floor.

Here's what that looks like in practice:

We're manufacturing products (dashboards, reports, insights) that nobody's buying (using).

But we keep the production line running.

Why? Because we're not measuring the right thing.

We measure:

✅ Time to build
✅ Data accuracy
✅ Dashboard performance
✅ Number of features

We don't measure:

❌ Actual usage
❌ Time to value
❌ Decisions influenced
❌ Products we should sunset

The Usage Analytics Framework

Here's how we started tracking what actually matters:

1. Instrument Everything

CREATE TABLE dashboard_usage (
  dashboard_id VARCHAR(50),
  user_id VARCHAR(50),
  viewed_at TIMESTAMP,
  time_spent_seconds INT,
  filters_applied JSONB,
  exports_generated INT
);

Track:

Page views (basic)
Time spent (engagement)
Filters applied (actual use vs casual browsing)
Exports/downloads (taking action on the data)

2. Define "Active Use"

Not just "someone opened it."

Active use = viewed + spent >60 seconds + applied filters OR exported data

This separates "accidentally clicked" from "actually using."

3. Run the 90-Day Audit

SELECT 
  dashboard_name,
  COUNT(DISTINCT user_id) as unique_users_90d,
  AVG(time_spent_seconds) as avg_time_spent,
  SUM(exports_generated) as total_exports
FROM dashboard_usage
WHERE viewed_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY dashboard_name
ORDER BY unique_users_90d DESC;

The results were brutal:

60% had zero active users in 90 days
20% had 1-2 users (probably just the creator checking it)
Only 20% had genuine regular usage

4. Sunset Process

We created a simple decision tree:

Zero active users in 90 days?
  ↓
Email the creator: "Dashboard X hasn't been used. Sunset in 30 days unless we hear otherwise."
  ↓
No response OR "yeah, nobody needs it anymore"?
  ↓
Archive it. Remove from production. And you can track very similar stats at the data level. It is as simple as who queries what when?

Result: Went from 47 dashboards to 12 in one quarter.

The remaining 12? Actually used. Actually maintained. Actually valuable.

The Pushback We Got

"But what if someone needs it later?"

Archive it. If they ask (they won't), restore it. In two years, nobody asked.

"But it took us months to build!"

Sunk cost fallacy. The cost of maintaining unused dashboards is higher than the cost of rebuilding if needed.

"But leadership asked for it!"

Leadership asked for it two years ago. They haven't looked at it since. Show them the usage data. They'll agree to sunset it.

"But I worked hard on it!"

I know. I did too on dashboards that are now archived. It hurts. But unused work is waste in manufacturing terms.

The Factory Floor Mindset

If you view analytics as manufacturing (which I do after reading The Phoenix Project), then:

Unused dashboards = inventory sitting in a warehouse

They cost money to maintain:

Data pipeline costs
Storage costs
Mental overhead ("should we update this?")
Confusion ("which dashboard is the source of truth?")

Better to:

Build less
Measure usage
Sunset quickly
Focus on what's actually used

The Sarah Chen Story

This is exactly what happens in Chapter 1 of the Analytics Pitfalls fable.

Sarah Chen joins ClassicMotors.io as Head of Analytics. Day one, she discovers 47 dashboards.

Leadership keeps asking "what does the data say?" but nobody can answer because they have too much data and not enough insight.

Sarah realizes: This isn't a data problem. It's a production problem.

She needs to audit what's actually being used, sunset the waste, and focus the team on the 20% that drives 80% of value.

Sound familiar?

Read Chapter 1 (free): analyticspitfalls.com/fable

Your Turn

Have you run usage analytics on your dashboards or your data?

If not, start here:

Instrument basic tracking (views, time spent)
Run the 90-day audit
Email creators of unused dashboards
Sunset what's not needed
Focus on what drives value

Drop your results in the comments. I'm betting most teams have 40-60% unused.

Let's stop building inventory nobody wants.

Discussion Questions

What % of your dashboards do you think are actually used regularly?
How do you track dashboard usage in your org?
What's your process for sunsetting unused analytics products?
Anyone else view analytics as a manufacturing floor?

This is part of my Analytics Pitfalls series - lessons from 25 years of data mistakes. Follow for more.

Previous: Garbage In, Powerhouse Out? (Nope.)

Garbage In, Powerhouse Out? (Nope.) Why Your Data Foundation Matters More Than AI

Brian Cariveau — Tue, 13 Jan 2026 00:57:13 +0000

"Garbage in, garbage out."

You've said it. I've said it. Every data engineer has said it.

Then we move on. We buy the next AI tool. We hire more data scientists. We build more dashboards.

Meanwhile, our data foundation is still garbage.

The Uncomfortable Pattern

After 25 years in data and analytics—from small business, through consulting, and on to Wells Fargo & UnitedHealth Group—I've watched the same pattern repeat. At Fortune 10 companies and scrappy startups alike:

Organizations spend millions on insights initiatives while their data is fundamentally broken.

I watched a company invest heavily in machine learning. World-class team. Sophisticated models. The demos were perfect.

Then they pointed the models at production data.

Everything broke.

Why? The foundation was garbage:

Inconsistent naming conventions
No data quality checks
Undocumented edge cases
Historical baggage nobody understood

The ML team had learned to solve problems that didn't exist in production.

"Stupidly Simple Data"

A colleague of mine, Matthew Stearns, coined a phrase that stuck: "Stupidly simple data."

Not "clean data." Not "governed data." Not "enterprise-grade architecture."

Stupidly. Simple. Data.

Data so simple that:

A new hire can understand it on day one
Your grandmother could read the table names
Edge cases are documented
There are no cryptic abbreviations
Everything is self-documenting

Sounds basic, right?

Most organizations have data that looks like this:

sls_txn_f47
usr_bhv_ag_01
car_lst_vw_2
tmp_final_v3_ACTUAL_USE_THIS

And when you ask what they mean? Nobody knows. The engineer who built them left two years ago.

The Day We Almost Lost "Stupidly Simple"

Let me tell you what happened when my team tried to practice what we preached.

We were building a cloud data warehouse from scratch. Clean slate. No legacy baggage.

We made a pact: No jargon. No abbreviations. No "lift and shift" thinking.

Three data layers:

Raw Data (not "bronze")
System Specific (not "silver")
Analytics Ready (not "gold")

Why not medallion architecture? Because going to Home Depot and asking "Where's the paint?" and hearing "It's in the silver department" is absurd.

Everything spelled out:

salesforce_opportunities_raw
google_analytics_sessions_cleaned
customer_lifetime_value_monthly

No sf_opp_raw. No ga_sess_cln. No cltv_mo.

The goal: stupidly simple.

When Standards Drift

About six months in, our system_specific schema started getting messy.

One of our data scientists: "You have got to be kidding me. This is getting messy. I thought it was supposed to be stupidly simple."

She was right.

The team had been using it as a staging area for AI experiments. Transitory tables nobody would ever query directly. Tables that should've lived somewhere else.

Here's the beautiful part:

Because everything was spelled out—because we'd held to no abbreviations—we knew EXACTLY which objects were AI staging tables.

We created a new schema: ai_model_staging

Moved everything over in a day.

system_specific was clean again. Back to stupidly simple.

The Standard That Enforces Itself

Here's what made this work:

"Stupidly simple" had become our language. Our shared value.

When we drifted, someone called it out. That data scientist didn't need permission to point out the mess. The standard gave her permission.

That's when simplicity becomes sustainable.

Not when it's written in a document nobody reads.

Not when it's enforced top-down by governance.

When it becomes the language your team uses.

The Technical ROI of Simple Naming

Let's talk actual impact:

Onboarding Time

Before (cryptic naming): 3-6 months for new data engineers to be productive
After (stupidly simple): 2-3 weeks

Debugging Time

Before: "What does usr_bhv_ag_01 mean?" → Slack thread → wait for someone who knows → maybe they respond
After: user_behavior_aggregated_daily → self-documenting → no questions needed

Refactoring Time

Before: "Which tables are AI staging?" → guess → break production → rollback → try again
After: ai_model_staging.* → clean migration in hours

Mental Overhead

Before: Everyone maintains mental map of abbreviations → tribal knowledge → lost when people leave
After: Zero translation needed → new hires productive immediately → knowledge doesn't walk out the door

The Foundation Nobody Wants to Build

Here's the truth: The foundation matters more than the fancy stuff.

More than AI. More than machine learning. More than real-time streaming or data lakes or whatever the next buzzword is.

If your data foundation is garbage, everything built on top of it is garbage.

You can't AI your way out of bad data.

You can't dashboard your way out of cryptic naming.

You can't innovate on fake problems and expect real solutions.

The Controversial Take

Want to be a powerhouse with data and AI?

Start with the boring stuff:

Stupidly simple naming
- No abbreviations, ever
- Self-documenting schemas
- Table names your grandmother could read
Real data, secured properly
- Not fake data theater
- De-identify where needed, but keep it real
- Test on production-like data
Clear ownership
- Every dataset has someone responsible
- Documented edge cases
- Quality checks that actually run
Self-documenting architecture
- New hires productive in days, not months
- No tribal knowledge requirements
- Code comments are last resort
Quality over quantity
- 5 trusted metrics beat 47 questionable ones
- Better to have less data that's reliable
- Ship working foundations, not complete messes

Not sexy. Not flashy. Not conference-worthy.

But it works.

Your Turn

If you've ever:

Inherited a database nobody could explain
Spent hours debugging cryptic table names
Watched new hires struggle for months
Built something on fake data that broke in production

Share your story in the comments. Let's learn from each other's mistakes.

Because the goal isn't perfection. It's progress.

People helping people.

Follow me here on Dev.to and connect on LinkedIn where I share more data engineering lessons learned the hard way.

Discussion Questions

What's the most cryptic database naming you've encountered?
How long does it take new data engineers to be productive on your team?
Do you use medallion architecture (bronze/silver/gold)? Why or why not?
What's your take on "stupidly simple" vs. more structured naming conventions?

Let's debate this. 👇