The following article was originally published on medium And is being republished here with the permission of the author.
You can carry with you a false confidence when you’re learning a new technique. You watch some videos, look at some documents, put a toy example to work, and say to yourself, “Yeah, I’ve got this.” I’ve done that. It never lasts. A hard lesson often comes with the only experience that matters.
You learn from failure – falling flat on your face, looking at the mess and figuring out why it broke. Anything that seems too easy? It probably was, and you didn’t come out of the process with anything worth learning.
Ask about failure: failure === experience
When I’m hiring someone who claims relational database expertise, I ask a “trick” question:
Tell me about the worst database schema you’ve ever created. What did it teach you to avoid?
It’s not really a trick. Anyone who has been deeply immersed in relational databases knows that there is no one correct schema. there are competitive use cases Which are constantly pulling against each other. You design for transactional workloads, but inevitably, someone tries to use it for reporting, everyone wonders why the queries crawl. Another developer on the team inadvertently adapts the schema for the reporting use case (usually years later) only to clutter the transactional workload.
The correct answer usually sounds like this:
We built for transactional throughput—one of the company’s founders thought MySQL was a database, which was our first mistake. The business then used it for reporting purposes. The system changed several times over the years. Joins broke, indexes did not match access patterns, and nightly jobs began to interfere with user traffic. We had to split read replicas, eventually set up a warehouse, and after 5-6 years, we simplified the transactions and moved them to Cassandra.
He is a person who has lived in give and takeThey have experienced a prolonged existential failure related to running the database, While they may not know how to solve some of the silly reasoning questions that are becoming increasingly popular in job interviews, it’s that kind of experience that is far more important to me,
The plan that almost broke me
I once sent a transaction schema that looked fine on paper: normalized, clean, everything in its proper place.
Then the analytics showed “only a few quick dashboards”. Next thing you know, my beautiful 3NF model, now attached to every elementary classroom in America, was being used like a million-row Excel spreadsheet to summarize an accounting report. For a few months, this was fine until it wasn’t, and the database took a slow faceplant because it was spending 80% of its time updating an index. It wasn’t like I could fix anything, as it would have meant several days of downtime as well as rewriting the project whose contract was almost up.
And how were we trying to fix it? If you have been in this situation, you will understand that what I am about to write is a sign that you have reached a new level of desperate failure. Instead of considering rational approaches to improving schema or separating “web-scale” workloads from NoSQL databases in 2007, we were trying to figure out how to buy a faster hard drive with higher IOPS.
I learned many things:
- I learned that upgrading hardware (buying a faster machine or spending a million dollars on a hard drive) will only delay your crisis. The real solution is inevitable—large-scale horizontal scaling is incompatible with relational databases.
- I learned the meaning of “query planning from hell”. We combined this with physical considerations and read the reproductions. Then we did what we should have done from day one: establish a real reporting path.
- If you have to optimize for a query plan every week? Your database is sending you an important signal, which you should translate as, “It’s time to start looking for an alternative.”
The text burned: Design for the use case you actually have, not the one you anticipate-And assume the use case will change.
What does this have to do with the cursor and Copilot?
I see a lot of people writing on LinkedIn and other sites about how amazing Vibe Coding is. These celebratory posts reveal more about the people posting them than they know, because they rarely acknowledge the reality of the process – it’s not all fun and games. While it’s amazing how much progress one can make in a day or a week, those of us who are actually using these tools to write code will be the first to tell you that we’re learning a lot of hard lessons.
It is not “easy”. There’s nothing “obvious” about this process, and if you’re doing it right, you’re starting to use expletives in your signals. For example, some of my prompts in response to a cursory agent yesterday were: “Are you kidding me, I have a rule that says I never wanted you to do this, and you ignored it?”
Whenever I see people get excited about the latest, greatest fad thing that’s changing the world, I’m the first to notice that they’re probably not using it. If they were, they would understand that it is not as “easy” as they are reporting.
The failure muscle you build with databases is exactly what you need with AI coding tools. You can’t go in quietly. You have to push until something breaks. Then you’ll figure out how to adopt new technology as a professional.
- Ask an agent to recreate a file—great.
- Ask it to coordinate changes to 20 files, rethink error handling, and keep passing tests—now we’re learning.
- See where it falters, and learn frame Work so that it can be successful next time.
- Spend the entire weekend on a “wild goose chase” because your agent coder decided to completely ignore your cursor rules. ← It’s expensive, but that’s how you learn.
The trick is not to avoid failure. Its fail in a controlled, reversible manner,
meta text
If you’ve never broken it, you don’t really know it. This is true for coding, budgeting, management, cooking, and skiing. If you haven’t failed, you don’t know it. And most people talking about “vibe coding” haven’t done it.
As an engineer the people I trust most can tell me Why something failed and How As a result he adjusted his approach. That’s the whole game with AI coding tools. The faster you can run the loop—try → break → observe → refine—the better you’ll get.
