Deliberate practice for programmers: why a green check isn't feedback

The reason your tenth year of experience can look a lot like your second year repeated ten times is that experience and practice are not the same thing. You can write code for a decade and plateau, because shipping features is not designed to make you better. It's designed to ship features. Improvement is a side effect, and an unreliable one.

The research term for the thing that actually moves the needle is deliberate practice, from Anders Ericsson's work on expert performance. It's the framework behind the people who get genuinely world-class at hard skills, and it has specific requirements. Repetition alone is not on the list. Most "I practice coding" routines miss the requirements entirely, which is why they don't work.

What deliberate practice actually requires

Ericsson's model has a few non-negotiable ingredients. Three of them matter most for us:

1. You work at the edge of your ability. Not the comfortable middle. The zone where you fail often enough to learn, on tasks just past what you can currently do.
2. You get immediate, specific feedback. Not "good" or "bad." Information precise enough to tell you what to change next time.
3. You repeat with correction. You take the specific feedback and run the rep again, adjusting, until the new pattern is automatic.

Pull on the second one, because it's where almost all coding practice quietly collapses.

The green-check loop

a result, not feedback

The deliberate loop

the feedback must be objective

A green check is not feedback

Submit a solution on a typical practice site and you get a green checkmark or a red X. That is a result, not feedback. It tells you that something is wrong, or that nothing detectably is. It does not tell you what, or why, or how far off you were, or what good would have looked like.

Compare it to how a good coach gives feedback. A swim coach doesn't say "that lap was bad." They say "your catch is dropping on the left; your elbow is sinking before your hand sets." Specific. Pointed at one fixable thing. Actionable on the very next rep. A green checkmark is the coach yelling "wrong!" from the deck and walking away. You can swim a thousand laps with that coach and fix nothing, because you were never told what to fix.

Worse, the green check actively hides the things worth practicing. This is correct, and it tells you nothing useful:

public int CountPairs(int[] nums, int target)
{
    var count = 0;
    for (var i = 0; i < nums.Length; i++)
        for (var j = i + 1; j < nums.Length; j++)
            if (nums[i] + nums[j] == target)
                count++;
    return count;
}

Green check. Ship it. Except it's O(n²), and on a large input it's the difference between a responsive endpoint and a timeout. The check told you "correct." It said nothing about the only property that matters at scale.

What real feedback looks like for a developer

So what would the swim-coach version look like for the snippet above? It would tell you, with numbers, exactly where you fell short:

Hidden test "n = 200,000": exceeded the 300 ms budget at 1,512 ms. Allocated 14 MB.

Now you have something to practice against. You know the what (too slow on large input), you have a magnitude (five times over budget), and the next rep has a target. One pass with a dictionary:

public int CountPairs(int[] nums, int target)
{
    var seen = new Dictionary<int, int>();
    var count = 0;
    foreach (var n in nums)
    {
        if (seen.TryGetValue(target - n, out var c))
        {
            count += c;
        }
        seen[n] = seen.GetValueOrDefault(n) + 1;
    }
    return count;
}

Resubmit: 1,512 ms drops to 7 ms, well under budget, a fraction of the allocations. That gap, felt and measured, is a real correction. You won't reach for the nested loop next time, not because you memorized a rule, but because you watched your own number collapse.

Specific feedback for a developer is concrete and quantified. It looks like:

• A timeout with the actual overage, not "too slow." 1,512 ms against a 300 ms budget.
• The real SQL your query generated, so an N+1 shows up as 40 round trips where 1 belongs, and a missing index shows up as a sequential scan in the plan.
• Structure metrics with a threshold: cyclomatic complexity, nesting depth, method length, duplication, scored, so "this is too complex" becomes a number you can drive down.
• An adversarial result, where a functionally-correct-but-vulnerable solution gets a specific exploit thrown at it, so "looks fine" turns into "blocked the SQL injection, broke nothing."

Every one of those is a coach pointing at one fixable thing. None of them is a green check.

Build the loop on purpose

Here's the practical takeaway, even if you never touch our product: stop measuring your practice by whether it passed. Measure it by whether you got information precise enough to change your next rep. If your practice can't tell you how slow, which queries, how tangled, or how it breaks, it's failing the deliberate-practice test, and you'll plateau no matter how many problems you grind.

That feedback loop is the entire thing Katabench is built around. Code is compiled and run server-side in an isolated sandbox, then graded on the axes above: time and memory with a budget, the generated SQL and query plan, Roslyn-measured structure, an adversarial exploit suite. The result isn't a checkmark; it's the specific, numbered, edge-of-ability feedback the model calls for. If the mechanics interest you, here's how the pipeline and sandbox work, and the guided labs sequence the work so each lesson sits just past the last.

Ten years of green checkmarks make you good at getting green checkmarks. A real feedback loop, run with correction, is what makes you good at the job. Pick a track and feel the difference on your next rep.