Last week, I aimed a very direct indictment at leadership. I told them that the massive cloud bill they are paying for their lift-and-shift migration is their own fault. They took an isolated, self-taught employee, handed them the keys to the legacy data estate, gave them zero architectural direction, and then acted surprised when the foundation cracked under consumption pricing.
We called that practitioner “Sarah.” The leadership got their warning.
Today, we are turning the camera around. We are talking to Sarah. We are talking to the field-promoted engineer who is currently staring down a modern cloud migration, feeling a knot of imposter syndrome in their stomach, and wondering if they actually know what they are doing.
I know exactly what it feels like to be in that seat.
I know because twenty-six years ago, I was Sarah.
The Isolation Trap
I spent the first eight years of my career in total isolation. I was the person who was “good with data.” I was plucked from the business, dropped into a data role, and told to make things work. I didn’t have formal education. I didn’t have a senior engineer to review my code. For the first big chunk of my career, Stack Exchange didn’t even exist. If I got stuck, I was hunting through random internet forum threads just trying to figure out how to write basic queries.
And under that pressure, I delivered. I got the reports out. I built the automations. I helped the business become more efficient.
But none of it was done right.
Looking back, I built exactly what you would expect an isolated person to build. Everything lived in the dbo schema because nobody ever told me it could be changed. I didn’t do any data modeling. I pulled data straight from the source and built what I now realize were bridge tables, but they were born purely out of necessity. I was just figuring it out as I went.
I was writing Survival SQL.
Survival SQL is code written for completion, not for performance. It is what happens when your only metric for success is “did the report run without throwing an error?” When you write Survival SQL, you don’t understand the compute engine. You just know what keystrokes make the red squiggly lines go away.
The Turning Point
Eventually, I moved to a new company. I was lucky enough to land under a leader who was an actual architect. He became my mentor.
He gave me my first project, and when I turned it in, he sat down to review my code.
He knew I was smart. He saw that I understood the syntax. But as he looked at my queries, the brutal truth became obvious to both of us. I knew absolutely nothing about modeling.
My code was running for tens of minutes when it should have taken seconds. I was defaulting to LEFT JOIN for absolutely everything. I was dumping every table into a single schema. I didn’t know what a Fact table was. I didn’t know what a Dimension table was. I had never heard the names Inmon or Kimball.
That is the exact moment the room goes cold. That is where imposter syndrome is born. You suddenly realize that you don’t know what you don’t know, and your entire foundational knowledge is built on quicksand.
The Indictment of Survival SQL
When you are self-taught and trying to get things done, you don’t know any better. You build a Tribal Knowledge Shield to protect yourself. But the moment you step out of your Comfort Zone and into a modern, consumption-based cloud environment, those survival habits become massive financial liabilities.
...those survival habits become massive financial liabilities. Look at the code below. This is what an isolated engineer builds.
Here are the three cardinal sins of Survival SQL:
The DISTINCT Crutch. You write a massive query, look at the output, and see duplicates. Instead of figuring out which join caused the fan-out, you just slap a DISTINCT on the final SELECT statement and call it a day.
The Hard Truth: DISTINCT is usually a confession. It is a confession that you do not understand the grain of your own data. You are forcing the compute engine to do a massive, expensive sorting operation to hide a flaw in your logic.
The LEFT JOIN Default. You use LEFT JOIN for every single table relationship because you are terrified of dropping records.
The Hard Truth: This is defensive coding. Every unnecessary LEFT JOIN forces the database engine to scan rows it should have cleanly eliminated. On a legacy on-prem server, that is a slow query. On Databricks or Snowflake, it is a recurring charge on the company credit card.
The dbo Junk Drawer. You leave every table in dbo because “it’s easier to find.”
The Hard Truth: You are not building a data platform. You are building a digital hoarder’s garage. If you do not impose physical layers on your data, you cannot impose governance, and you cannot secure it.
The Extraction Protocol
You cannot survive a modern cloud migration by doing what you did for the last ten years. You have to break your own habits. If you want to stop being a 10-Year Junior and become a true Data Engineer, here is your extraction plan.
Step 1: Fix the Grain, Kill the DISTINCT. Take your three most frequent queries. Remove the DISTINCT clause. When the rows duplicate, trace the data lineage back to the exact join that caused the fan-out. Fix the relationship. Understand the primary keys. Stop hiding the symptom and fix the disease.
Step 2: Audit your Joins. Go through your production scripts. Unless you have a specific, documented business requirement to retain null values from a target table, change your LEFT JOIN statements to INNER JOIN. Let the database engine eliminate the garbage data early.
Step 3: Evict the Junk Drawer. Stop treating Medallion Architecture like a marketing buzzword. It is a governance model. Create strict schema boundaries today. Separate your raw landing tables from your standardized intermediate tables. If a table doesn’t have a defined layer and a defined owner, it is a liability.
Step 4: Learn the Physics of Modeling. Stop building massive, flat, 100-column tables for every report. Read Kimball. Learn the difference between a Fact table (the verbs of your business) and a Dimension table (the nouns of your business). A well-designed Star Schema will solve performance problems that no amount of cluster-scaling ever could.
...A well-designed Star Schema will solve performance problems that no amount of cluster-scaling ever could. Here is the physical difference between accretion and architecture:
The Verdict
Imposter syndrome is just your survival instinct telling you that your skills are devaluing in a modern market.
Listen to it.
I spent eight years building the wrong way. The only difference between a career that stagnates and a career that scales is getting the right direction at the right time.
You did what you had to do to survive the legacy era. Now, you have to learn how to engineer for the future.
Stop writing Survival SQL. Start building assets.
If you are a veteran engineer realizing that your foundation is full of cracks, don’t wait for a failed technical interview to wake you up. You don’t have to figure this out in isolation anymore.
Join the Gambill Data Coaching Program. We don’t do happy paths or vendor hype. We tear down your code, fix your architecture, and turn field-promoted survivors into production-grade engineers. Book a intro call today.