A new note from matklad distills a lot of software design advice into two compact slogans: push ifs up, and push fors down. The idea is not that every conditional or every loop is bad. It is that code often becomes simpler when the decision-making moves outward and the work itself becomes more linear. The note argues for that pattern in a way that is easy to apply, but also intentionally framed as a rule of thumb rather than a strict law.
The first half of the note is about preconditions. If a function is checking whether it should do anything at all, matklad suggests that the caller may be a better place for that branch. When the precondition moves outward, the function itself can assume the input is valid and proceed straight through. That can reduce the number of checks in the system overall, because the same condition does not need to be repeated at multiple layers. It also makes the control flow easier to see, since the branching logic is concentrated in one place rather than spread through helper functions.
The note says that concentration can reveal things that are otherwise hard to notice. A dead branch is easier to spot when one function owns the decision tree. Redundant conditions are easier to collapse when the branching logic sits side by side. The point is not just tidiness. It is that control flow is one of the main sources of bugs, so taking it out of leaf functions can make those leaf functions easier to trust.
The second half of the note applies the same logic to data volume. Matklad argues that many systems naturally operate on batches, not single items, and that the batch version should often be the base case. That is a data-oriented way of thinking: if a program usually handles many entities, design for the many first. The scalar case can then become a smaller special case. Once you do that, you can amortize startup cost, change processing order, and even apply vectorized or struct-of-arrays tricks that are awkward when everything is written around one object at a time.
One of the note's more interesting examples is FFT-based polynomial multiplication. It is offered not as a deep derivation but as an illustration of the pattern: when you can evaluate many things at once, the batch form can unlock a completely different performance profile. The same underlying principle also appears in the note's discussion of a dissolving-enum refactor, where multiple branches turn out to be the same condition in disguise. Moving those branches upward makes the duplication visible.
What gives the piece its force is its balance. It is terse, but it is not simplistic. The advice is about reducing accidental complexity, not about worshipping a single style. Some functions really do need internal branching, and some loops really do belong where they are. Still, the note makes a strong case that many day-to-day code paths are easier to understand when the conditions are handled once, high up in the call tree, and the work beneath that point is kept as straight-line as possible.
That is the practical takeaway: push the decisions up, push the repeated work down, and keep the hot path obvious. For readers who already think in terms of refactoring and data-oriented design, the note is a concise reminder of why those instincts often pay off.
