Deliberate Practice and the Hidden Architecture of Python Expertise

Deliberate Practice•Mar 9, 2026•~17 min

Section 01Why I'm writing this

I've spent more than thirty years writing software, the last twenty-plus in investment banking, much of that in quant development and front-office risk, where the cost of a subtle bug is measured in real money and the cost of a slow developer is measured in missed deadlines that move markets. Across those years, in some roles, I've also trained other developers. A pattern became impossible to miss. The strongest engineers weren't the ones who'd written the most code or read the most books. They were the ones whose internal picture of how the language actually behaved was sharper than everyone else's. They had built models the rest of us were still working from fragments of.

This article is about the mechanism that builds those models. Specifically: what cognitive-science researchers call deliberate practice, what K. Anders Ericsson's research actually established, and what it looks like applied to Python. It is also the design thinking behind Codivium, the Python mastery platform I'm building. If the first three articles in this series argued that tutorials and projects leave a critical gap, that what they fail to build is a small set of internal models, and how to actually train, this one pulls the threads together and shows the cognitive science that explains why the approach works.

Section 02The comfortable trap

The completion of individual tasks, the ticking off of projects, gives a sense of achievement that can easily be mistaken for growing competence. If the approach used in successive projects is more or less the same, following tutorials, copying solutions from searches, staying within familiar patterns rather than pushing boundaries, plateauing is more likely than not.

From a distance it looks like progress. But the gaps remain where they have always been. Not confronted, not dismantled, just circled around, hidden behind competence and routine. The breaking point comes when the question itself changes. When you stop asking "how do I get this finished?" and instead demand of yourself "where is my thinking still shaky, and how do I sharpen it until it no longer breaks?" That shift is the threshold. It is the moment effort stops being maintenance and takes the first step on the path to genuine growth.

Section 03What Ericsson actually found

Psychologist K. Anders Ericsson spent decades studying how expertise develops in fields where performance can be measured and mistakes examined: musicians in conservatories, chess players, athletes, surgeons. What he found challenges the most convenient story we tell about excellence.

Natural talent, he established, is not the deciding factor. Neither is sheer volume of practice. The people who kept improving didn't simply put in more hours. They practised differently. They worked on the skills they were worst at, chose tasks just beyond their current ability, sought honest and frequent feedback on their performance, and returned to the same difficulties until progress was undeniable. Those who plateaued practised a similar number of hours but spent them in comfort. Repeating what they already knew. Staying in familiar routines. Steering away from situations that clearly exposed weakness.

The popular distillation of this research, that 10,000 hours makes a master, is, as Ericsson himself repeatedly clarified, wholly misleading. The variable that matters is not how much time you invest. It is the quality and structure of the practice during that time. Professionals who coast on autopilot for years often plateau early. Those engaging in structured, feedback-rich practice continue improving. Unfocused repetition preserves mediocrity. Structured, difficult, feedback-rich practice drives genuine improvement.

Deliberate practice, properly understood, has five defining features:

Targeted. Focused on specific sub-skills rather than vague improvement. Drill down until you reach the atomic skills that actually matter.
Progressive. Calibrated just beyond your current ability. If it doesn't feel hard, it isn't deliberate.
Immediate feedback. You need to know when you're getting it right or wrong, so you can adjust while the mental state that produced the error is still active.
Goal-oriented. Repetition with a clear purpose. Return to the same difficulty until the skill holds firm.
Mental models. The goal is internal representations that let experts not only perform differently from novices, but think differently.

These five features are not independent virtues. They operate as a system. Removing any one of them degrades the whole.

Section 04The four mental models every Python developer must build

Not all models are equal in their impact. Some are peripheral, useful to have but not devastating to lack. Others are foundational. They underpin so much of how Python behaves that gaps in them ripple outward into almost everything you write. There are four in this second category. Each is treated in depth in Article 2 of this series, with worked code. Here I'll show one example to illustrate why this kind of thing matters.

Consider this small piece of Python:

def append_to(item, target=[]):
    target.append(item)
    return target

print(append_to(1))
print(append_to(2))
print(append_to(3))

Before you read on: what does this print?

It prints [1], [1, 2], [1, 2, 3]. The default argument target=[] is evaluated once, when the function is defined, not each time it is called. The same list survives between calls. Every invocation mutates it. The developer who predicted three independent single-item lists has a model treating defaults as recreated per call. That model is wrong, and it sits at the intersection of two of the four foundational areas: the memory model (names bind to objects) and the execution model (when defaults are evaluated).

The four foundational areas, in summary:

The execution model. What the interpreter is doing at each step, how the call stack grows and shrinks, how a function invocation suspends one context and creates another. This matters enormously when reasoning about recursion, generator behaviour, why a stack trace reads the way it does. A developer with a sharp execution model reads a traceback and immediately understands the chain of events that produced it. A developer without one reads the same traceback and starts guessing.

The memory and identity model. Variables do not store values. They bind names to objects. When you write x = [1, 2, 3] and then y = x, you have not created two lists. You have created two names pointing at one list. The implications cascade. Why mutating a list inside a function changes it outside. Why default mutable arguments are a notorious trap. Why copying objects requires more thought than intuition suggests. The developer who internalises this model eliminates an entire category of bugs from their code, not by being more careful, but by understanding.

Scope and namespacing. Python resolves names through a hierarchy: local, enclosing, global, built-in. Understanding this hierarchy is essential for writing code that behaves predictably. Why does a closure capture a variable rather than its value? Why does a global modified in one module affect another? These are not quirks to memorise. They are logical consequences of a scoping system that, once understood, becomes entirely predictable.

Data structures and cost. Knowing what a dictionary is differs sharply from knowing when to reach for one. The model here is not a catalogue of definitions but an intuitive grasp of complexity, memory cost, and access patterns. The automatic recognition that searching a list grows linearly while looking up a dictionary key does not, and that this distinction matters when your data has ten thousand records rather than ten.

The cost of getting these wrong

The consequences of poorly formed models are not always dramatic. Sometimes they are. A production bug that took a week to diagnose. A performance issue that required a rewrite. More often the cost is quiet and cumulative. The debugging session that runs an hour longer than it should. The architectural decision that seemed reasonable until it wasn't. Each intervention is a guess dressed as a diagnosis. Some guesses happen to work, which creates the dangerous illusion of understanding. The underlying model remains uncorrected. Three weeks later, a subtly different version of the same bug reappears.

Most developers attribute these problems to insufficient experience. They are usually wrong. The actual constraint is almost never the volume of experience. It is the depth of a small number of foundational models. Fix the models, and the symptoms disappear, not through greater effort, but through greater clarity.

Section 05Why micro-challenges work where projects don't

If models are what we are trying to build, then the question becomes one of method. What kind of practice actually forges them? The intuitive answer, build more projects, write more code, accumulate more experience, turns out to be largely wrong. Or rather, inefficient. Projects improve procedural familiarity and deepen comfort with workflow. They are a poor mechanism for building internal models.

The reason is signal-to-noise. When you build an application, you integrate dozens of concepts simultaneously. When something works, or when something breaks, it is very difficult to isolate which concept is responsible. The feedback loop is long, the variables many, the specific mechanism that produced the outcome usually obscured by the complexity surrounding it.

Micro-challenges work differently. A micro-challenge is a small, tightly scoped exercise designed to isolate a single concept and force direct engagement with it. It is not primarily about writing code. It is about predicting code. A well-constructed micro-challenge presents a short function and asks: what does this return, and why? Before running it. Before checking. The developer must reach into their model, make a prediction, and commit to it.

This is where the cognitive science becomes directly relevant. When you make a prediction and receive immediate feedback on its accuracy, your brain enters a state of active model revision. Cognitive scientists call the gap between prediction and outcome prediction error. Prediction error is precisely the signal the brain uses to update its internal representations. A prediction that turns out to be correct confirms the model. A prediction that is wrong, the more valuable case, exposes exactly where the model is inaccurate and forces a revision.

The struggle is not incidental to the process. It is the process.

Passive reading produces no prediction error. A tutorial, however well made, produces no prediction error. You watch, you follow, you nod, and your model remains exactly as it was, because it was never tested. A micro-challenge that surprises you is doing something fundamentally different. It creates the precise cognitive conditions under which learning actually occurs.

This is the design logic behind Codivium's micro-challenge system. Each exercise is built around a single Python mechanism. The learner sees a short snippet of code, makes an explicit prediction about what it does, commits to that prediction, and only then sees the answer. The answer arrives with diagnostic feedback that names the specific assumption that broke, not just whether the answer was right. The next exercise targets a related but distinct corner of the same mechanism, so the model has to discriminate rather than rehearse. This is what micro-challenges look like in practice. Not a quiz. A controlled environment for putting prediction error to work.

Section 06Why struggle comes before guidance

There is a habit so universal among developers that it has become invisible. The reflex, when a problem resists immediate solution, to reach for help. Stack Overflow, a colleague, a language model, the answer key. The impulse feels rational. Why spend twenty minutes struggling when the answer is thirty seconds away? The calculus, however appealing, is almost exactly backwards. The struggle is not the obstacle to learning. It is the mechanism.

The attempt-first principle

Psychologist Robert Bjork's research on what he calls desirable difficulties established something counterintuitive and important. Conditions that make learning feel harder in the short term produce dramatically stronger retention and transfer over time. Struggling with a problem before receiving its solution is one of the most robust examples of this effect. The effort the struggle requires is not wasted. It is the effort that makes the subsequent learning permanent.

When you attempt a problem without knowing the answer, your brain is not passively waiting for input. It is actively constructing and testing hypotheses, recruiting existing knowledge and testing its reach, identifying the precise edges of what it understands. When guidance arrives after genuine struggle, it lands in a mind already oriented toward it. The question was live. The answer resolves it. When the answer arrives before the struggle, the question was never live, and the answer resolves nothing.

Related to this is what memory researchers call the generation effect. Information you generate yourself, even incorrectly, is retained significantly better than information you are simply told. The wrongness of an incorrect attempt is not the problem. It is part of the mechanism.

What attempt-first looks like in practice: before reaching for any external resource, before searching, before asking, before checking, write out what you think the answer is. Articulate where your understanding runs out. Make a prediction. Identify specifically where your reasoning becomes uncertain. Codivium's hint system is built around this principle. Hints are layered, and each layer unlocks only after a genuine attempt has been recorded. The first hint nudges the learner toward the right question. The second narrows the territory. The final layer reveals the answer with reasoning. The structure is designed not to bypass the struggle but to reward having genuinely engaged with it first.

How real feedback differs from simply checking a solution

Most developers, when they think about feedback, think about checking answers. This feels like feedback. It is a pale and often misleading imitation of it. Checking a solution puts you in a comparative mode: does my answer match theirs? Real feedback puts you in a diagnostic mode: why was my reasoning correct or incorrect, and what does the discrepancy reveal about my model?

Useful feedback requires specificity. Feedback that tells you your answer is wrong is not useful. Feedback that tells you your answer is wrong because your model of Python's name binding is inaccurate, and that this specific inaccuracy produced this specific error, is feedback that can change something. The specificity is not optional. It is the mechanism by which feedback improves performance rather than merely registering it.

Self-explanation, the feedback tool you already have

Self-explanation is perhaps the most accessible high-impact learning technique, and the most consistently underused. The principle: narrate your own reasoning, aloud or in writing, as you work through a problem. Not describing what you did. Explaining why you did it, what you expected to happen, and why you believe the outcome was what it was.

For a Python developer this is two distinct habits. Before writing code, narrate what you are about to do and why. I am reaching for a dictionary here because I need constant-time lookups and the relationship is key-value structured. After an error, rather than simply fixing it, explain what your model predicted, why it predicted that, and precisely where prediction and reality diverged. The second habit, applied consistently, is what transforms error correction into actual learning.

Error analysis: making failure into information

Most developers have a default response to error: fix and move on, or feel frustrated and move on faster. Both treat the mistake as an obstacle to clear rather than a resource to mine. The underlying model that produced the error goes unexamined. Three weeks later, a subtly different version of the same mistake reappears, because its root cause was never identified.

The distinction that matters is between fixing and understanding. Fixing means changing code until it behaves correctly. Understanding means identifying the precise gap in your model that made you write the incorrect code in the first place. A developer who fixes without understanding is patching a wall without asking why it is cracking.

A structured sequence for error analysis: What did I predict would happen? What actually happened? What does the gap reveal about my model? Which specific model is inaccurate? What would I need to understand differently for my prediction to have been correct? This sequence turns the error from a frustration into a diagnostic instrument of considerable precision.

Section 07What a session actually looks like

The principles of deliberate practice are, at a certain level, not difficult to understand. What is difficult is what it actually looks like when you sit down to do it.

A practice session for a Python developer has a definable shape. It is not a working session. The goal is not to produce something, but to improve something. A working session succeeds when a task is completed. A practice session succeeds when your understanding of a concept is deeper at the end than it was at the beginning.

A session begins with a narrow target. Not improve at Python but deepen my understanding of how Python resolves names in closures. The target should be specific enough that you could describe exactly what competence in it looks like, and exactly what your current gap is. From there the session moves through a cycle: attempt, apply attempt-first fully, receive feedback, perform self-explanation on the outcome, revise your model, repeat. The session ends not at a fixed time but when concentration begins to degrade. That is a reliable signal that the cognitive load required for real practice has been reached.

Ericsson's research consistently found that expert performers rarely engaged in more than four hours of practice per day, and that sessions of one to two hours represented the typical upper limit of genuinely productive effort. For a working Python developer fitting practice into an already demanding schedule, even thirty to forty-five focused minutes will produce significantly better results than two hours of unfocused problem-solving. The variable that matters is not duration but intensity of engagement.

Frequency matters more than session length. Daily practice, even brief, compounds more effectively than longer sessions less often. The reason is consolidation. The neural processes that integrate new learning into long-term memory operate most effectively when practice is distributed across time rather than massed into infrequent longer sessions.

Working below your skill ceiling wastes time. Working far above it produces confusion rather than learning. The target is the zone of proximal challenge: difficult enough to require full cognitive engagement, accessible enough to make genuine progress possible. Identifying this ceiling requires honesty most people find uncomfortable. It means testing yourself on material you are not confident about, observing where your predictions fail, and targeting those failure points rather than the areas where you already perform well.

The final component of a well-structured session is often omitted: a few minutes of reflection on what the session revealed. What specifically did you learn? What did you discover about your model that you did not know before? What will the next session target, and why? This reflection consolidates the session's learning and maintains continuity of direction. It is what transforms isolated practice into a coherent developmental arc.

Section 08You don't know what you don't know

There is a particular species of ignorance that makes deliberate practice difficult to begin: the ignorance that doesn't announce itself. Most of the knowledge gaps that genuinely limit a developer's growth are invisible. Not because the developer lacks the intelligence to see them, but because the gaps sit in the blind spots created by what they do know. You cannot feel the absence of a concept you have never encountered. You cannot notice the flaw in a model until the model is tested against something it cannot explain.

A Python developer who is strong in object-oriented design may feel broadly competent in the language while having significant gaps in their understanding of concurrency, memory management, or the subtleties of Python's data model. The strength in one area generates a halo of assumed competence that extends further than the actual competence reaches. These hidden gaps surface unexpectedly. In technical interviews. In code reviews. In production incidents. They are more damaging than gaps the developer is aware of, precisely because the awareness that would prompt remediation is absent.

The solution to invisible gaps is systematic external testing. Assessments designed not to confirm what you know but to expose what you don't. A good diagnostic does not reward confident performance on familiar material. It probes the edges of understanding, surfacing the specific points where knowledge transitions from solid to uncertain to absent.

This is what Codivium's diagnostic MCQ system is built for. The questions are not trivia. Each one is constructed as a targeted concept probe: a short Python snippet that distinguishes a robust model of a foundational mechanism from a shaky one. Distractor answers are chosen to match common misconceptions, so getting a wrong answer tells you not only that you got it wrong but specifically which misconception you were holding. The diagnostic outputs a profile of which of the foundational areas is your weakest, and a recommended starting point. The whole thing takes five minutes.

One distinction most diagnostic approaches miss: there is a difference between not knowing something and not being able to use it under pressure. A developer may be able to explain what a generator is and still write inefficient code that would benefit from one, because the model for when to deploy it has not been built. Knowledge gaps are addressed by learning. Application gaps are addressed by practice, the kind of targeted, feedback-rich practice that builds the recognition that makes knowledge deployable under pressure.

The practical output of systematic diagnostic assessment is a gap map: a structured, living record of the specific areas where your understanding is incomplete, organised by type (knowledge vs application) and by priority. Article 3 of this series describes the gap map in detail, with a worked example. Each session has a target drawn from the map. Progress is visible and measurable. The practice has direction.

Find your gap

Take the free five-minute diagnostic. Ten short Python prediction questions, scored across the four foundational areas, with a personalised report on which of your models is the shakiest.

Take the diagnostic →

Section 09The compounding effect

Deliberate practice is not a technique that produces immediate dramatic results. This is a feature rather than a bug, and understanding why is essential to sustaining the commitment long enough to experience its effects.

Motivation is a weather system. It fluctuates, responds to circumstances, and cannot be relied upon as the primary driver of any long-term developmental programme. The alternative is to build practice as a system rather than a feeling. A fixed structure in the day that does not depend on enthusiasm to activate. A defined time, a defined duration, a defined source of targets drawn from the gap map. The session happens regardless of how the day has gone, in the same way that a professional musician does not audition their desire to practise before practising. The system produces consistency. Consistency produces compounding.

Most developers, when they track progress at all, measure activity rather than capability: hours logged, problems completed, courses finished. These are comfort metrics. A developer can complete fifty problems without improving if the problems were below their skill ceiling. Meaningful progress tracking measures different things: prediction accuracy on diagnostic challenges over time, error rates on specific categories of problem, the ability to explain concepts in your own words with precision. These are capability metrics. Direct evidence that the models are improving rather than just that effort is being applied.

The reason deliberate practice produces such dramatically different outcomes from conventional practice, given sufficient time, is compounding. Each session builds on a model slightly more accurate than it was the session before. Better models generate better predictions, which generate more informative errors, which generate more precise corrections. The system feeds itself.

In the early months, this compounding is not yet visible. Progress feels slow, and the discomfort of working at the edge of ability is a constant companion. This is when most self-directed learners abandon the approach. Precisely when it is working as designed. The inflection point comes somewhere between six and twelve months of consistent practice, and when it arrives it is unmistakable. Problems that were previously difficult become accessible. Patterns that were previously invisible become obvious. The experience of genuinely hard material shifts from threatening to interesting. The ceiling has risen.

Expertise, as Ericsson's research defines it, is not a state of final achievement. It is a direction. A sustained orientation toward the edge of one's ability, maintained over years, producing continuous incremental refinement of the models that underpin performance. An expert Python developer is not someone who knows everything about the language. They are someone whose models are sufficiently deep and accurate that they can reason confidently about unfamiliar problems, learn new material faster than novices, and transfer understanding from one context to another with minimal friction.

The markers are qualitative as much as quantitative. Problems begin to feel structured rather than opaque. Debugging shifts from trial-and-error to hypothesis-driven investigation. Code review becomes a conversation about principles rather than a catalogue of corrections.

Section 10From principles to practice

The challenge with deliberate practice is the gap between understanding the principles and actually applying them. Most of the resources available to Python developers are not built for deliberate practice. They are built for engagement, for completion, for the satisfying experience of following a well-structured path from start to finish. Tutorials give you the answer before you struggle with the question. Course exercises are designed to confirm understanding, not to expose its limits.

Deliberate practice requires a specific environment. Challenges calibrated to the edge of your current ability. An enforced attempt-first protocol. Immediate and specific feedback tied to the underlying mechanisms rather than the surface outcome. Diagnostic assessment that identifies gaps rather than confirming strengths. These requirements are not incidental. They are the conditions under which genuine skill development occurs.

The minimum viable habit, which any developer can start tomorrow, looks like this. Identify one specific mechanism in Python that your model of is uncertain. Find or design a small challenge that will test that model directly. Attempt it without any assistance. Explain your reasoning before seeing the outcome. Analyse the gap between your prediction and the result. Record what the gap reveals about your model. Do this for thirty focused minutes, three to five times per week, with targets drawn from a maintained gap map.

This is not complex. It is demanding. Consistently, deliberately, uncomfortably demanding. It is also the approach the evidence supports.

Mastery is not a summit. It is a change in the quality of attention. The point at which Python stops being a language you work in and becomes a language you think in. What it feels like, on the day you first notice it, is simply this: the problem that used to threaten you now interests you.

That change does not come from reading about it. It comes from the repeated, effortful discipline of testing your understanding against reality, session after session, until the gap between what you predict and what happens quietly closes.

Get the full series

The four articles in this series are available as a single, designed PDF: a portable compendium you can read offline or share with colleagues.

Download the series →

Be first in line

Codivium opens for early access soon. The platform implements every principle in this article, with hundreds of micro-challenges across the foundational models, an attempt-first hint system, diagnostic MCQs, and an automatic gap map that carries your weak points across sessions. Join the waitlist to be first in when it goes live.

Join the waitlist →