You know the story from Atomic Habits.

A pottery teacher splits the class into two groups (well Atomic Habits uses photography, but the orginal story is about pottery). The “quantity” group gets graded on weight, make 50 pounds of pots, get an A. The “quality” group gets graded on perfection, make one perfect pot, get an A.

End of semester? The best pots all came from the quantity group.

James Clear uses this to prove quantity beats quality. Make more, get better. Volume trumps perfectionism.

He’s half right.

What Clear’s Story Misses

There’s a third group nobody talks about. The group that combines both approaches and destroys them.

Rapid iteration with intentional learning.

Not just making 100 pots hoping one turns out good. Not planning the perfect pot for three months without touching clay.

Building fast, breaking deliberately, learning what actually matters vs. what the documentation says matters.

I Just Proved This (By Accident)

Last month I needed to understand Kubernetes infrastructure for some upcoming opportunities. I could have:

• Quantity approach: Spin up 50 test clusters, hope something sticks
• Quality approach: Plan the perfect architecture, read every best practice, never actually build it

Instead: I built a production-grade 6-node RKE2 cluster in my basement. Got it running. Then started breaking things on purpose.

What I deployed:

• 3 control plane nodes, 4 workers
• HAProxy load balancing
• Rancher management platform
• Full monitoring stack
• Real SaaS workload (my actual application, not hello-world)

Then I chaos-tested it:

• Moved control plane storage to NVMe to see performance impact
• Ran chaos monkey to understand failure modes
• Killed nodes during operation to test HA
• Overloaded workers to find resource limits
• Deliberately misconfigured networking to learn what breaks

This took about two weeks. Taught me more than six months of webinars ever could.

But here’s why it worked better than pure quantity OR quality:

The Three-Part Pattern

1. Build something you actually need

Not a practice project. A real workload with real consequences. My hosting company (300+ customers) runs on this infrastructure. When something breaks, I feel it immediately.

Stakes create attention. Attention creates learning.

2. Rapid iteration without perfectionism

Got hello-world running? Ship it. Move to production deployment. See what breaks in reality vs. theory.

I didn’t spend three weeks planning the perfect cluster. I built good-enough, then used reality as my teacher.

3. Intentional destruction

This is what the pottery class story misses entirely.

After pot #10, did the quantity group ask: “What made #7 better than #6? What specific technique am I improving?” Or did they just keep making pots?

I didn’t just run my cluster. I deliberately broke it:

• What happens when a control plane node dies during an update?
• How does the load balancer handle backend failures?
• Where are the actual bottlenecks vs. where I thought they’d be?

Every failure taught me something I couldn’t learn from documentation.

Why This Beats Both Approaches

Quantity without reflection = lots of experience, slow learning

You make the same mistakes differently 100 times. Progress exists but it’s inefficient. You learn eventually through pure volume.

Quality without execution = perfect plans, zero feedback

You optimize for imaginary problems. Build elegant solutions to the wrong constraints. Never learn what actually matters because you never ship.

Combination = exponential learning

Build fast enough to get feedback loops. Break things deliberately to understand failure modes. Reflect on what actually moved the needle vs. what was just motion.

The Real-World Test

Here’s how you know if you’re doing it right:

Bad quantity: “I built 50 test clusters” Bad quality: “I designed the perfect architecture” Good combination: “I built a cluster for my actual application, chaos-tested it until I understood every failure mode, and now I know exactly which complexity is necessary vs. which is just impressive-sounding bullshit”

The difference? One gives you résumé bullets. The other gives you capability.

This Is How I Stay Current With Technology

Not certifications. Not webinars. Not reading documentation cover-to-cover.

Build something real. Break it deliberately. Learn from the wreckage. Iterate.

Every technology I actually understand came from this pattern:

• Build for real need (stakes matter)
• Ship before perfect (feedback loops matter)
• Break intentionally (failure modes matter)

The pottery class metaphor works, but Clear stopped too early in the analysis.

Quantity beats quality when you’re completely paralyzed.

But quantity with reflection beats both—and it’s not even close.

What Are You Forcing That Should Be Redirected?

Right now, are you:

• Planning the perfect thing that never ships?
• Churning through repetitive work without learning?
• Or building real things, breaking them deliberately, and extracting the actual lessons?

Most people optimize for looking productive. Few optimize for actually learning.

The gap between those two determines how fast you compound capability.

Build something real. Break it on purpose. Learn what actually matters.

That’s the system.

This article is part of Hocus Pocus Focus (HPF) – making sense of technology, business, and building things that last. For the technical implementation of what I learned building this Kubernetes cluster, see the companion article: “Building a Production-Grade RKE2 Kubernetes Cluster: A Practical Guide“