Why performance is NOT learning (and what it means for you)

First, let's define the terms:

• Performance is the ability to complete a task or demonstrate knowledge in the moment - often boosted by having everything in working memory, repetition, familiarity, or significant environmental cues. For example, AI co-pilots and internal tooling can turn complex tasks into simple button-clicks. It's what shows up when you just manage to get the job done and:

  refers to the temporary fluctuations in behaviour or knowledge that can be observed and measured during or immediately after the acquisition process

  — Soderstrom & Bjork, 2015

• Learning, on the other hand, is deeper. Essentially, learning is a change in long-term memory. If this didn't happen - you didn't learn anything. If performance is what you can do now, learning is what you can do in the future once the freshness has worn off. Learning:

  refers to the relatively permanent changes in behaviour or knowledge that support long-term retention and transfer

  — Soderstrom & Bjork, 2015

Here's the problem: performance and learning are not the same.

What looks like success on the surface - e.g., getting your code to run - isn't the same as the ability to maintain it or solve the next problem. This distinction highlights the divide between performance and learning.

This illusion of progress is why many professionals plateau in their careers as individual contributors (ICs). By focusing on immediate results, they miss the deeper learning required to grow into more complex roles or adapt to new technologies.

It feels good to perform well. It gives us confidence. Our brains are wired to favour immediate feedback, and we often mistake these short-term boosts for genuine understanding.

Research led by Robert Bjork (1994) highlights this illusion. He introduced the concept of "desirable difficulties" - the idea that conditions that make learning harder (like spacing out the learning, mixing topics, or testing yourself) actually enhance long-term retention.

The problem is these techniques don't always make you feel like you're succeeding in the moment. That's where the confusion happens and why we find it easy to tell ourselves performance is learning.

Here's why (the right kind of) struggle is good:

1. Effort improves encoding. When your brain has to work harder, it creates stronger neural connections. For example, debugging a problem without immediately looking up a solution creates stronger connections than simply copying an answer from StackOverflow or an AI.
2. Spacing prevents forgetting. Revisiting material after some time has passed forces your brain to rebuild the memory, strengthening it further. In fact, you actually want the forgetting process to kick in a little bit before forcing yourself to recall. Too soon and it's too easy, diminishing the strengthening effect. For example, revisiting a concept like recursion after a few weeks strengthens your ability to use it in different contexts.
3. Mixing challenges transfer. Practicing in varied ways helps you apply what you've learned in new contexts. For example, alternating between front-end and back-end development tasks strengthens your ability to integrate both, making you more adaptable in full-stack roles.

If you're only able to get through your day-to-day tasks with the use of AI and lots of environmental cues, you're setting yourself up for challenges down the line when these things are taken away.

Imagine starting a new job and realising your skills were propped up by your old company's tools. Don't let that happen to you.

Practically, there are a few things you can do to help yourself:

1. Push beyond copy-paste solutions. When solving a problem, start by writing pseudo-code or comments before diving into coding. Limit reliance on existing patterns until you've tried your own solution first.

   Challenge: Try to solve at least one problem entirely from memory each week, writing pseudo-code before consulting external resources.

2. Review and reflect. Document your debugging process after solving a tough issue. Revisit it later to identify gaps or inefficiencies - this will improve your problem-solving speed and accuracy over time.

   Challenge: Pick one completed task each week and write a short post-mortem: what went well, what didn't, and what you'd do differently next time.

3. Don't fool yourself. Perhaps the most insidious impact of this confusion is that it tricks us into thinking we've developed skills or knowledge which we don't actually possess and thus sets us up for a rude awakening at a later date.

   Challenge: Ask yourself this after completing a task: "Could I explain why this solution works to someone else? Could I reapply this skill in a new context?" If the answer is no, revisit the problem and identify gaps in your understanding.

This isn't about avoiding tools or embracing needless struggle - tools are obviously essential for productivity, and efficient workflows matter. But if your goal is learning, you need to focus on changing long-term memory, as performance alone is a poor indicator of true understanding.