How to Become an Expert: What Practice, Feedback, and Research Actually Show

Expertise Is Not Just Time Spent

We often describe expertise with years: ten years in an industry, twenty years playing an instrument, thousands of hours writing code. Time matters because complex skills require exposure, but elapsed time is only a rough measure of what happened during those years.

A person can repeat the same comfortable workflow for a decade and become extremely efficient at that workflow without becoming equally strong at the harder situations around it. Another person can improve faster because every week includes new problems, correction, review, and a reason to change how they work.

That distinction is useful because it changes the question. Instead of asking only how long someone has been doing something, ask what kind of learning their experience contained. Did they receive feedback? Were mistakes visible? Did the difficulty increase? Did they have to update their mental model? Expertise grows from the quality of the learning process, not from a calendar by itself.

Experience gives you opportunities to learn. It does not guarantee that learning happened.

Practice Is Not the Same as Deliberate Practice

K. Anders Ericsson, Ralf Krampe, and Clemens Tesch-Römer made deliberate practice central to the modern discussion of expertise. In their 1993 Psychological Review paper, deliberate practice referred to effortful activities designed specifically to improve performance, rather than simply performing the skill for enjoyment or repeating what already feels natural.

That means the uncomfortable part is not a side effect. It is often the point. Deliberate practice isolates a weakness, gives it focused attention, measures the result, and repeats the process. A pianist may work on a difficult passage instead of playing the entire piece from beginning to end. A developer may reproduce a performance bottleneck, profile it, test one hypothesis at a time, and compare the result instead of only writing more features.

The TED-Ed lesson by Annie Bosler and Don Greene makes this idea easy to visualize. Effective practice is focused, repeated, and directed at improvement. It also emphasizes reducing distractions, starting slowly when necessary, using frequent repetitions with breaks, and mentally rehearsing established physical skills.

• Choose a specific weakness instead of practicing everything at once.
• Work near the edge of your current ability, where mistakes are still likely.
• Make the result observable so you can tell whether the change helped.
• Repeat with correction instead of repeating the same mistake more confidently.

A Useful Four-Part Model for Expertise

The Veritasium video frames expertise around four conditions: repeated attempts, an environment with learnable patterns, timely feedback, and deliberate practice. I like this model because it explains why experience produces strong intuition in some domains and misleading confidence in others.

Daniel Kahneman and Gary Klein reached a related conclusion in their 2009 paper on intuitive expertise. They argued that skilled intuition is most likely to develop when the environment contains sufficiently regular cues and when the learner has enough opportunity to learn those cues through experience. In other words, intuition becomes trustworthy when reality gives you patterns and repeatedly tells you whether you read them correctly.

Robin Hogarth, Tomás Lejarraga, and Emre Soyer later described a similar distinction between kind and wicked learning environments. A kind environment gives feedback that helps you connect actions with outcomes. A wicked environment can hide, delay, distort, or reverse those relationships, making experience much harder to interpret.

• Repeated attempts: you need enough real encounters with the problem to build a useful library of experience.
• A valid or learnable environment: there must be patterns that can actually be discovered and reused.
• Timely, meaningful feedback: you need to know whether your judgment or action was right, wrong, or incomplete.
• Deliberate practice: you still have to work on weaknesses instead of staying inside the comfortable part of the skill.

Feedback Is What Turns Repetition Into Learning

Repetition without feedback can make a habit stronger even when the habit is wrong. Feedback closes the loop. It gives you evidence that your current approach worked, failed, or needs adjustment.

The best feedback is close enough to the action that you can connect cause and effect. A compiler error appears immediately. A chess move eventually produces a tactical consequence. A coach can point out why a movement failed while the attempt is still fresh. Tests, analytics, user behavior, code review, and production incidents can all serve the same function in software work when they are interpreted carefully.

Delayed feedback is not useless, but it is harder to learn from because many other variables can change before the outcome appears. This is one reason some domains produce better expert intuition than others. When outcomes are noisy or arrive months later, people can become experienced without receiving enough clean information to correct their judgment.

Pattern Recognition Changes What You See

One of the most interesting features of expertise is that experts do not merely think faster. They often perceive the situation differently because long-term memory contains organized patterns that beginners do not yet have.

Classic chess research by William Chase and Herbert Simon showed that stronger players could reproduce meaningful chess positions far better than novices after brief exposure. The advantage was tied to recognizing familiar structures in realistic positions, not to possessing unlimited general memory. Experts can compress many individual details into meaningful chunks because they have seen related configurations before.

This is why an experienced developer can sometimes look at a bug report, a network trace, or a strange layout shift and immediately suspect a small set of causes. It can feel like intuition, but much of that intuition has been built from earlier cases: the failed deployment, the race condition, the caching issue, the CSS rule that behaved differently than expected, and the hours spent finding out why.

The important limitation is that pattern recognition is domain-specific. Being excellent at one kind of problem does not automatically make someone an expert in every adjacent field. Expertise is powerful precisely because it is built around a large, structured history of relevant situations.

The 10,000-Hour Rule Is Not a Rule

The popular idea that anyone becomes an expert after exactly 10,000 hours is an oversimplification. Ericsson's work helped inspire that number in popular culture, but the research did not establish a universal timer that produces expertise at hour 10,001.

A 2014 meta-analysis by Brooke Macnamara, David Hambrick, and Frederick Oswald found that deliberate practice was meaningfully associated with performance, but the size of that relationship varied substantially across domains. In their analysis, deliberate practice explained more performance variation in games, music, and sports than it did in education and professional work. The authors concluded that deliberate practice matters, but it is not the entire explanation for differences in performance.

A 2019 replication of part of Ericsson's original violin work also found that the most accomplished violinists did not fit a simple story in which more accumulated deliberate practice explained every difference among elite performers. Opportunity, instruction, starting conditions, physical constraints in some domains, motivation, access to training, and other individual differences can matter too.

So the useful lesson is not to count hours obsessively. Count high-quality learning cycles. One hour spent attacking a real weakness with good feedback can be more valuable than several hours spent repeating what you can already do comfortably.

Do not chase a magic number of hours. Chase better learning loops.

Why Experience Can Plateau

Once a skill becomes good enough for everyday work, the environment may stop forcing improvement. You know the tools, your output is accepted, and the same solutions continue to work. That is useful professionally, but it can also create a plateau.

Improvement resumes when something exposes the gap between current ability and a higher standard. That might be a stronger opponent, a demanding reviewer, a new codebase, a stricter performance target, a coach, a failed assumption, or a project that cannot be solved with your usual approach.

This is also why expertise and ego can conflict. The fastest way to discover what you still need to learn is to enter situations where your current model is incomplete. If being wrong feels unacceptable, you start protecting the appearance of expertise instead of building the real thing.

An expert mindset is therefore not knowing everything. It is having a deep model of a domain while remaining willing to update it when evidence says something different.

What This Looks Like in Software Development

Software development is a useful example because the feedback loop can be extremely fast. You write something, run it, inspect the result, read the error, change the code, run a test, review the diff, and repeat. Used well, that loop is a deliberate-practice machine.

But simply shipping tickets is not automatically deliberate practice. If every problem is solved with the same pattern and nobody reviews the result deeply, a developer can become faster without expanding much. Growth happens when the work exposes new constraints and the person studies the result instead of only moving to the next task.

A production issue can teach architecture. An accessibility audit can change how you build interfaces. A slow page can force you to understand browser rendering, network waterfalls, caching, and image delivery. A checkout bug can teach you how several systems interact. The lesson becomes reusable when you do more than patch the symptom and ask what underlying model was missing.

• Reproduce the problem before changing code whenever possible.
• Form a hypothesis instead of making many unrelated changes at once.
• Use tests, profiling, logs, review, and user behavior as feedback.
• Write down the root cause, not only the final fix.
• Return to the same class of problem later and see whether you recognize it faster.
• Increase the difficulty intentionally instead of staying only with work you can already do quickly.

A Practical Loop for Getting Better at Almost Anything

There is no universal recipe that guarantees expertise in every domain, but the research suggests a practical loop that is much more useful than waiting for years to pass.

• Define the skill narrowly. 'Get better at programming' is vague; 'diagnose frontend performance bottlenecks' gives you something observable to improve.
• Attempt real problems repeatedly. Build enough exposure that patterns have a chance to appear.
• Get feedback. Use a coach, reviewer, test, score, measurement, opponent, customer, or other reliable signal from the domain.
• Study mistakes. Ask which assumption was wrong and what cue you missed.
• Correct the model, then repeat. The next attempt should include something you learned from the previous one.
• Raise the difficulty. When the current version becomes automatic, add complexity, speed, precision, pressure, or a new constraint.
• Protect recovery. Effortful practice has limits; breaks and sleep are part of learning, not evidence that you are avoiding it.

Attempt, feedback, correction, repeat, then make the problem harder.

Expertise Should Make You More Precise About What You Do Not Know

The more I think about expertise, the less useful the label feels as a finish line. Real expertise is local. Someone can be outstanding in one area and ordinary in another. A strong engineer can be new to a framework. A black belt can still be learning a position. A musician can master one repertoire and struggle with another style.

That is not a contradiction. It is what domain-specific knowledge looks like. Expertise gives you deeper patterns, better questions, faster recognition, and stronger judgment inside a field. It does not remove uncertainty or make every intuition correct.

For me, the best takeaway from these videos and the research behind them is simple: keep creating situations where reality can correct you. Practice what is still difficult. Look for feedback. Study the pattern behind the mistake. Then try again with a better model.

You do not become an expert by finally reaching a point where there is nothing left to learn. You become more expert by getting better at learning from the next attempt.