{"id":351347,"date":"2025-12-17T15:39:08","date_gmt":"2025-12-17T15:39:08","guid":{"rendered":"https:\/\/www.newsbeep.com\/ca\/351347\/"},"modified":"2025-12-17T15:39:08","modified_gmt":"2025-12-17T15:39:08","slug":"if-youve-never-broken-it-you-dont-really-know-it-oreilly","status":"publish","type":"post","link":"https:\/\/www.newsbeep.com\/ca\/351347\/","title":{"rendered":"If You\u2019ve Never Broken It, You Don\u2019t Really Know It \u2013 O\u2019Reilly"},"content":{"rendered":"

The following article originally appeared on\u00a0Medium<\/a>\u00a0and is being republished here with the author\u2019s permission.<\/p>\n

There\u2019s a fake confidence you can carry around when you\u2019re learning a new technology. You watch a few videos, skim some docs, get a toy example working, and tell yourself, \u201cYeah, I\u2019ve got this.\u201d I\u2019ve done that. It never lasts. A difficult lesson often accompanies the only experience that matters.<\/p>\n

You learn through failure\u2014falling flat on your face, looking at the mess, and figuring out why it broke. Anything that feels too easy? It probably was, and you didn\u2019t exit the process with anything worth learning.<\/p>\n

Ask About Failure: Failure === Experience<\/p>\n

When I\u2019m hiring someone who claims relational database expertise, I ask a \u201ctrick\u201d question:<\/p>\n

Tell me about the worst database schema you ever created. What did it teach you to avoid?<\/p>\n

It\u2019s not really a trick. Anyone who\u2019s been knee\u2011deep in relational databases knows there\u2019s no perfect schema. There are\u00a0competing use cases\u00a0that constantly pull against each other. You design for transaction workloads, but inevitably, someone tries to use it for reporting, then everyone wonders why queries crawl. Another developer on the team inadvertently optimizes the schema (usually years later) for the reporting use case only to make the transactional workload unworkable.<\/p>\n

The correct answer usually sounds like:<\/p>\n

We built for transactional throughput\u2014one of the founders of the company thought MySQL was a database, which was our first mistake. The business then used it for reporting purposes. The system changed hands several times over the course of several years. Joins became gnarly, indices didn\u2019t match the access patterns, and nightly jobs started interfering with user traffic. We had to split read replicas, eventually introduce a warehouse, and after 5\u20136 years, we ended up simplifying the transactions and moving them over to Cassandra.<\/p>\n

That\u2019s a person who has\u00a0lived the trade-offs. They\u2019ve experienced a drawn-out existential failure related to running a database. While they might not know how to solve some of the silly logic questions that are increasingly popular in job interviews, this is the sort of experience that carries far more weight with me.<\/p>\n

The Schema That Nearly Broke Me<\/p>\n

I once shipped a transactional schema that looked fine on paper: normalized, neat, everything in its proper place.<\/p>\n

Then analytics showed up with \u201cjust a couple of quick dashboards.\u201d Next thing you know, my pretty 3NF model, now connected to every elementary classroom in America, was being used like a million-row Excel spreadsheet to summarize an accounting report. For a few months, it was fine until it wasn\u2019t, and the database had made a slow\u2011motion faceplant because it was spending 80% of its time updating an index. It wasn\u2019t as if I could fix anything, because that would mean several days of downtime coupled with a rewrite for a project whose contract was almost up.<\/p>\n

And how were we trying to fix it? If you\u2019ve been in this situation, you\u2019ll understand that what I\u2019m about to write is the sign that you have reached a new level of desperate failure. Instead of considering a rational approach to reform the schema or separating what had become a \u201cweb-scale\u201d workload in 2007 from a NoSQL database, we were trying to figure out how to purchase faster hard drives with higher IOPS.<\/p>\n

I learned a lot of things:<\/p>\n

I learned that upgrading hardware (buying a faster machine or dropping a million dollars on hard drives) will only delay your crisis. The real fix is unavoidable\u2014massive horizontal scaling is incompatible with relational databases.I learned the meaning of \u201cquery plan from hell.\u201d We band\u2011aided it with materialized views and read replicas. Then we did what we should\u2019ve done from day one: set up an actual reporting path.If you are having to optimize for a query plan every week? Your database sending you an important signal, which you should translate to, \u201cIt\u2019s time to start looking for an alternative.\u201d<\/p>\n

Lesson burned in:\u00a0Design for the use case you actually have, not the one you hope to have\u2014and assume the use case will change.<\/p>\n

What Does This Have to Do with Cursor and Copilot?<\/p>\n

I\u2019m seeing 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 realize, as they rarely acknowledge the reality of the process\u2014it\u2019s not all fun and games. While it is astonishing how much progress one can make in a day or a week, those of us who are actually using these tools to write code are the first to tell you that we\u2019re learning a lot of difficult lessons.<\/p>\n

It\u2019s not \u201ceasy.\u201d There\u2019s nothing \u201cvibey\u201d about the process, and if you are doing it right, you are starting to use curse words in your prompts. For example, some of my prompts in response to a Cursor Agent yesterday were: \u201cYou have got to be kidding me, I have a rule that stated that I never wanted you to do that, and you just ignored it?\u201d<\/p>\n

Whenever I see people get excited about the latest, greatest fad thing that\u2019s changing the world, I\u2019m also the first to notice that maybe they aren\u2019t using it all. If they were, they\u2019d understand that it\u2019s not as \u201ceasy\u201d as they are reporting.<\/p>\n

The failure muscle you build with databases is the same one you need with AI coding tools. You can\u2019t tiptoe in. You have to push until something breaks. Then you figure out how to approach a new technology as a professional.<\/p>\n

Ask an agent to refactor one file\u2014great.Ask it to coordinate changes across 20 files, rethink error handling, and keep tests passing\u2014now we\u2019re learning.Watch where it stumbles, and learn to\u00a0frame\u00a0the work so it can succeed next time.Spend an entire weekend on a \u201cwild goose chase\u201d because your agentic coder decided to ignore your Cursor rules completely. \u2190 This is expensive, but it\u2019s how you learn.<\/p>\n

The trick isn\u2019t avoiding failure. It\u2019s\u00a0failing in a controlled, reversible way.<\/p>\n

The Meta-lesson<\/p>\n

If you\u2019ve never broken it, you don\u2019t really know it. This is true for coding, budgeting, managing, cooking, and skiing. If you haven\u2019t failed, you don\u2019t know it. And most of the people talking about \u201cvibe coding\u201d haven\u2019t.<\/p>\n

The people I trust most as engineers can tell me\u00a0why\u00a0something failed and\u00a0how\u00a0they adjusted their approach as a result. That\u2019s the entire game with AI coding tools. The faster you can run the loop\u2014try \u2192 break \u2192 inspect \u2192 refine\u2014the better you get.<\/p>\n","protected":false},"excerpt":{"rendered":"The following article originally appeared on\u00a0Medium\u00a0and is being republished here with the author\u2019s permission. There\u2019s a fake confidence…\n","protected":false},"author":2,"featured_media":351348,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[49,48,61],"class_list":["post-351347","post","type-post","status-publish","format-standard","has-post-thumbnail","category-technology","tag-ca","tag-canada","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/posts\/351347","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/comments?post=351347"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/posts\/351347\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/media\/351348"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/media?parent=351347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/categories?post=351347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/ca\/wp-json\/wp\/v2\/tags?post=351347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}