In 2017, I published a short reflection on the 10,000-hour rule and its relevance to programming. Years later, I find myself returning to that idea—not to reaffirm it, but to reframe it.

This time, through the lens of antifragility.

The 10,000 Hour Rule Revisited

The 10,000-hour rule, popularized by Malcolm Gladwell (and originally studied by Anders Ericsson), suggests it takes about 10,000 hours of deliberate practice to achieve mastery in a complex field.

In programming, this might mean:

~20 focused hours a week for 10 years
A combination of personal projects, code reviews, team work, refactoring
Exposure to failure and success in equal measure

But time, by itself, isn’t enough.

The Shift to Quality: What You Practice Matters

In retrospect, much of my earlier programming time was "exposure," not "deliberate practice." I wrote code, but I wasn't necessarily thinking in terms of concepts, patterns, architecture, or feedback loops. It was progress—but not the kind that compounds.

Deliberate practice in programming means:

Thinking about how you think — not just solving, but reflecting
Learning to name what you’re doing (pattern recognition, flow control, system decomposition)
Isolating weak points, even outside your comfort zone (naming, testing, debugging strategies)

From Resilience to Antifragility

Inspired by Nassim Taleb’s concept of antifragility, I started to see learning not as protection from chaos, but as the use of chaos to get stronger.

Antifragile code and developers don't just survive under stress — they adapt, generalize, and emerge better:

Code that improves under edge cases, rather than breaks
Teams that learn from bugs, instead of just patching them
Habits that seek exposure to variation, not stability alone

Why This Matters in the Era of AI

Today, tools like ChatGPT, GitHub Copilot, and CodeWhisperer can write basic code for us. The value of the developer has shifted from writing code to thinking about why this code, here, now, for this system.

That’s a mental shift.

In this world, we don't just accumulate hours. We cultivate intuition, create tools, build prompts, and — when necessary — compress language itself to think more clearly.

The future developer isn't the one who wrote more lines of code.
It's the one who knows which parts of the system should never be brittle.

A Few Practical Takeaways

If I were giving advice to my younger self (or to a curious beginner), it might sound like this:

Log your confusion. Every "why is this weird?" moment is a hidden mentor.
Look for structure, even in play. Ask “what's the hidden shape of this project?”
Practice editing, not just building. Write five solutions and throw four away.
Accept entropy. Bugs, detours, and errors are not distractions — they are the data.
Build micro-tools. Even if they're not used, you’ll see patterns emerge.

In Closing

I no longer count hours.
I count friction, feedback, and flow.

And I believe this — antifragile thinking — will be the real differentiator for developers in the years to come.

From 10,000 Hours to Antifragile Thinking: How We Learn to Code Better