#069: The Power of Naming in Data Projects (especially w/ dbt)

Naming is powerful in a data project because a good name tells you what an object is before you open it. A naming convention is a repeatable, agreed pattern for what models, tables and columns are called, and in a dbt project you set it from a blank slate. With a clear convention, a prefix like stg_ or fct_ tells you the layer, the shape of the data and what you can expect inside, with no thinking required. Without one, every developer invents their own prefixes and abbreviations, and parsing a single query becomes a rabbit hole only the original author understands. The decision is not glamorous, and there is plenty of ego involved, but it directly affects your time, your energy and how fast new people can contribute.

Why naming is a hard conversation

For most data teams, naming conventions are one of the more challenging discussions you'll have. There is a lot of ego and a lot of strongly held opinions involved.

It is also incredibly important, especially in dbt, where you start from a blank slate and every decision you make early sets the pattern. Get it right and it saves time, energy and possibly money along the way. Here are the three reasons why.

Reason 1: You understand context faster

The first reason is that good naming helps you quickly understand the context of whatever you're working on. What is this query, what is this table or view, what does this object represent.

With clear, consistent names you don't have to think hard about any of that. It sounds obvious. The reality on most teams is different.

How naming gets lost

When teams first get started they build models quickly. It's easy, and they need results out the door. The side effect is that things get pushed through without a clear structure.

Different developers build their own way: their own prefixes, their own abbreviations, their own shortening. Within one directory, models can look completely different from each other.

Then the project scales and nobody has time to refactor. New members join, more variety gets added, and over time you get rabbit holes of names that follow no structure at all.

Now the top layer is confusing, and inside any query the table references are a rabbit hole of their own. Often only the original developer really understands it. That's a big waste of time and energy before you ever get to adding value.

What a good convention tells you

Naming won't solve every problem, but a clear and repeatable convention changes how you read a project. Open a query, see the staging models, and you know where the data comes from without a second thought.

The name also tells you what to expect, because the layer carries meaning:

• stg_ models. A staging model is one to one with the source data. If your team deploys staging as views, you immediately know it's a view with no joins.
• fct_ models. A fact table in a star schema holds keys and metrics, so you know what columns to expect.
• dim_ models. A dimension is context only, so there won't be metrics inside.

The exact rules vary by team. The point is that when your strategy and your naming are consistent together, the mental workload of figuring out what's going on drops dramatically.

Why it compounds

In the moment this feels uneventful. It's not a grand change. But think about how many queries you'll write, how many models you'll open, how many new developers will join.

Every one of those is a moment where you don't have to spend mental energy on context. Good naming and good structure save a lot of headaches, and they apply to reviewing other people's changes as much as to your own work.

Reason 2: It keeps the project consistent

Clear naming keeps your project consistent, and again that sounds obvious. The value isn't that the project looks nice and organized. The value is in the secondary benefits:

• Easier to navigate. You know where things live and what they are.
• Easier to change. You can make edits with confidence about what you're touching.
• Easier to review. You can analyze what other people are doing and make recommendations that keep the project consistent.

Together those make you and the whole team more efficient.

The creativity objection

The biggest pushback on a consistent, repeatable format for model naming, and even more so for query formatting, is that it limits creativity. Development is almost an art form for a lot of us. We're not drawing, but writing code is our form of creative expression.

There's truth to that, and there's a trade off. But we were hired to do a job. We're on a team, building an analytics platform for the business, not building whatever we want because we feel creative.

Our customers are the business stakeholders. The more efficient we are, the more impact we have for them. Time and mental resources shouldn't go to tracking down what a query means because of inconsistent naming.

It's one less thing to think about

A naming rule doesn't take away your creativity. It takes away a decision. With that decision gone, your mental energy goes to the higher level, abstract work: the logic, and the connections between models, views and the other objects in the project.

That is where the real value of our skills lives, not in what we chose to call a table.

Leaders set the tone

A lot of this comes down to the leaders on the team and the expectations they set and enforce. That applies whether or not "leader" is your title. If you're the one setting the tone for what things should look like, consistency starts with you.

Reason 3: Faster onboarding

Most of us won't be on the same team, at the same company, or working on the same code for our whole careers. We'll be gone at some point, and new people will join. Naming lives beyond our own time on the project.

The cost of an inconsistent project

If the project is all over the place, it's hard for anyone to pick up what you did after you leave. It's also hard to onboard people while you're still there.

You end up explaining edge cases, and accounting for why somebody did something a different way. The more of those there are, the more the team looks disorganized.

It's also hard to ask someone to follow rules when you or your team never followed them in the first place.

What a consistent project gives a new developer

With clear conventions in place, a new person can come in and pick up where you left off, or just copy what you did and follow the same workflow.

They pick things up faster and, more importantly, contribute faster. They know what's expected and what the rules are, so they can apply their own abilities within the conventions instead of guessing at them.

Why this matters to me personally

As an independent consultant, my client relationships are usually temporary. I help set up a foundational dbt project, set the conventions and provide the documentation, then I move on.

If I'm not following clear conventions myself, and just building quickly without structure, I can't expect the team to stay organized after I leave. Strong conventions are what give the project a real shot at scaling once it's in their hands.

Related reading

• Why Bother With Naming Conventions?
• Are Strict Data Conventions Helpful or Overkill?
• dbt Project Naming Conventions: Recommendations
• 3 Must-Haves for Any SQL Style Guide

Final takeaway

Every foundational dbt project I set up for a client starts with the naming conventions, because that is what the team inherits when I leave. It will be tempting to move fast and name things however you see fit. Decide the conventions up front instead, and every query, review and new hire from then on gets a little easier.