Mixing different problems together and studying one topic at a time train two different things. Mixing trains you to choose between options you could confuse. Studying one topic trains you to see what a set of examples share. Which one you need depends on which of the two you cannot do yet.
You spend an evening like this. Two pointer exercises, then a set of Linux commands, then back to a Makefile tutorial you left half finished. Maybe you were following advice about mixing your practice, or maybe it simply ended up that way.
You touched three subjects and finished none. It did not feel like better practice. It felt like a worse version of the evening before.
The advice about mixing is real. It has a condition attached, and the condition is the part that matters.
We have said this before: mixing helps when the problems are close enough that you have to decide which approach applies. That was one line inside a longer argument about why you can understand a topic and still not apply it. What it leaves out is the useful part — what mixing is for, what studying one topic at a time is for, and how to tell which one you need this week.
Practising one kind of problem at a time removes the step where you decide which kind it is.
What mixing your practice trains
Put two kinds of problem in front of you in an order you cannot predict. Before you can solve anything, you have to work out which kind you are looking at.
That step is invisible when you practise one kind at a time. If every question on the page is pointer arithmetic, you never decide that it is pointer arithmetic. The page decided for you.
Mixing takes that help away, and the work it adds is the work of telling things apart. Practice mixed this way is called interleaving. Tested across a lot of material — pictures, word lists, maths problems, not kernel code — it comes out ahead more often than not, which is why you keep meeting the advice. Applying it to engineering is our own extension.
But it helps by making you choose. So it works when the things you mix could be mistaken for each other. When they could not be confused, there is no choice to make, and the mixing gives you nothing.
What studying one topic at a time trains
Studying one topic at a time is not the lazy option that mixing corrects. It has its own job. It is called blocked practice, and for some material it wins outright.
Consider race conditions. A driver and its interrupt handler writing one buffer. A counter updated from two threads. A file two processes read and rewrite at once. On the surface they look unrelated, and until you can name what they share, each one is a separate story.
What they share is this: two paths touch the same state, and nothing decides which goes first. That sentence is the thing being learned, and meeting the examples close together is what lets you write it.
Mixing mostly trains you to tell things apart. Grouping mostly trains you to see what they share. Neither is the advanced version of the other.
Notice what does the work there. Not the exposure. You can sit through five examples and come away with five examples. The sentence is the work, and if you have studied one topic at a time for years without getting faster, that is usually the step nobody made you take.
It is also the missing reason behind advice we have given you before. When we said that eight weeks on the driver model beats eight weeks spread across eight areas, the reason was not simply that focus is good. While you are still assembling that sentence, an unrelated subject takes away the comparison that writes it.
Which of the two problems do you have?
So the question is not which schedule is better. It is which of the two you cannot do yet.
- You keep picking the wrong method. You know how to use a mutex and a spinlock, and can explain both. Faced with unfamiliar code you cannot tell which context you are in. Your problem is selection, and mixing confusable problems is what trains it.
- You cannot say what the examples share. You have seen several memory leaks, or several use-after-free bugs, and each one still feels like a separate story. Your problem is abstraction, and grouping is what trains it.
If both look true, group first. Mixing examples you cannot yet describe leaves you nothing to choose between.
That also settles something we have argued in two places. Elsewhere we said to widen the range of problems rather than the depth of one when you are testing real competence. Widening is for after the sentence exists. Grouping is for while you are writing it.
Why this does not go away when you get experienced
You spend a week on four jobs: a build failure, a customer bug, a code review, a proof of concept. The week is full of variety. It looks like mixed practice.
Mostly it is not, and the reason is not that the four are unalike. It is that each one arrived labelled. You knew which was which before you opened it, so the choosing had been done for you, exactly as the page of pointer problems did it for you.
A week spent on four labelled jobs is not varied practice. It is four first days.
This is a different complaint from one we have made before. We have argued that years of work are not years of practice because the corrections never come back to you. That is about feedback arriving. This is about the choosing being done in advance. Both can be true of the same person at once.
How to tell which one you need
Open a problem and watch your first few seconds. If you know which method applies before you have read it properly, nothing in front of you is making you choose. Elsewhere we have treated answering before you finish reading the question as a habit to suppress, and it is. Read it as information as well.
The opposite signal matters as much. If you have worked through several examples and still cannot write the one sentence that covers them, you are not ready to mix.
What to do this week
If the problem is abstraction, take five examples of one idea, sit with them in one session, and write the sentence that covers all five. Then test the sentence: find something it wrongly includes, and narrow it. A sentence that covers everything is not a sentence.
If the problem is selection, you need problems you could genuinely confuse, and those are harder to find than variety. Ask an assistant for varied practice and you get variety. Ask instead for problems where two named calls would both compile and only one is correct — mutex against spinlock, kmalloc against vmalloc — and tell it not to say which is which. Shuffle them, and write your guess down before you work each one.
Before you solve the problem, write down what kind of problem you think it is. The mistakes you make there are the ones worth counting.
Our sessions are built in the same order. The scenario arrives before anyone names the technique, because a problem that comes to you already labelled has done the half you came to learn.
None of this makes the mixing advice wrong. Across everything that has been tested it wins more often than it loses, which is exactly why the exception is worth knowing. When answers are cheap, the scarce skill is knowing which question you are in front of, and only practice that makes you choose will build it.
— Raghu Bharadwaj
