Juggling and the Brain
Learning to juggle physically rewires the brain. The same incremental pattern that builds a juggler builds an engineer. No prerequisites. The feedback is immediate.

Juggling looks like a parlour trick. Three balls, two hands, an audience that reacts at the right beat. Under the hood, it is one of the densest cognitive workouts you can do standing still. The research backs that up.
And the learning pattern that builds a juggler is structurally identical to the one that builds a software engineer, a machine learning practitioner, or anyone adding a new tool to a production system.
The brain physically changes
A landmark study at the University of Regensburg found that adults who learned a basic three-ball cascade over three months showed measurable increases in grey matter in two regions:
- The mid-temporal area, which processes moving objects
- The left posterior intraparietal sulcus, which integrates spatial and motor information
A follow-up study at Oxford extended the finding to white matter. Juggling reshapes not just where neurons live but how they connect.
The changes appear in older adults too, though more slowly. The catch is reversibility: stop practising for three months and most of the gain disappears. Use it or lose it, in the most literal sense.
What this means for learning technology: the same reversibility applies. Engineers who stop coding, consultants who stop building, architects who stop reading system designs: the pattern degrades. Maintenance is not optional.
Go deeper: Test-Driven Development and Operational Excellence
Three months. Three balls. Visible changes on a scan.
The brain does not treat juggling as a trick. It treats it as a problem worth building new infrastructure for. That infrastructure persists for as long as you keep using it.
The learning loop you cannot shortcut
The reason juggling builds the brain so effectively is structural. You cannot go straight to five balls. You learn one ball reliably, add a second, then a third. Each step is a small failure that teaches the next correction. There is no theory phase. The feedback is immediate and physical.
This incremental pattern has a direct analogue in machine learning:
| Juggling | Machine learning |
|---|---|
| One ball, then two, then three. Each level locked in before adding load. | Incremental learning rate schedules: slow ramp, validate, ramp again |
| Eyes on the apex, not the hands | Watch the leading indicator, not the lagging one |
| Drop a ball mid-pattern; recover the rhythm before chasing the ball | Incident response: stabilise the system first, root-cause second |
| Add a fourth ball: the pattern is no longer cascade, it is fountain | Past N concurrent users, the architecture fundamentally changes shape |
The teams that learn fastest, whether people or ML models, are the ones that build reliable patterns at each level before adding the next one. Skipping levels is how you drop everything at once.
Go deeper: Gradient Descent and Backpropagation
Attention has a budget
Every juggling pattern has an attention budget. Not money: cognitive capacity. Each prop in the air requires a fraction of the juggler’s tracking capacity.
A three-ball cascade costs a certain amount. A five-ball cascade costs substantially more. The number of simultaneous trajectories that must be tracked, predicted, and corrected grows faster than the number of props.
At some point, the budget runs out. Adding a sixth ball does not require ten percent more attention. It requires a completely different mode of processing. Some jugglers never reach it, not because they lack practice hours, but because the underlying system reaches its limit before the skill arrives.
This is the same structure as:
- LLM context windows. An 8k window and a 128k window are not the same architecture scaled up. Quality degrades at the edges of long contexts even when compute is available.
- Microservice monitoring. A team tracking 12 services without distributed tracing is running 12 untracked objects in the air. The clubs fly fine. The question is whether the system can locate them all when one deviates.
- Codebases that exceed the comprehension budget of the team maintaining them.
Knowing when a system has exceeded its attention budget is a skill. Jugglers learn to feel it. Engineers learn to instrument for it.
Four trajectories. Each requires tracking, prediction, and correction. Simultaneously.
The question is not whether you can add one more. It is whether the system tracking all of them degrades before you reach the drop. Instrument before you scale.
Peripheral vision as a system design principle
The skill that separates good jugglers from great ones is not reflexes. It is peripheral vision.
You do not stare at one ball. You hold all of them in soft focus and detect deviation before it becomes a drop. You train this by knowing what normal looks like. The moment something moves outside the expected arc, it registers before you consciously process it.
In software: this is monitoring and observability. You do not log into each server to check it manually. You collect metrics, logs, and traces from all services simultaneously. A dashboard gives you soft-focus visibility across the whole system. When one service begins to deviate, an alert fires before it drops.
The juggler cannot develop peripheral vision without first knowing the normal arc of each ball. Neither can an on-call engineer develop effective alerting without first instrumenting what normal looks like.
You build the peripheral vision by internalising the pattern first.
Go deeper: Prometheus and Operational Excellence
Focus is a side-effect of the pattern
There is a state jugglers describe after a few minutes of continuous practice: thoughts stop, the pattern takes over, the body runs the loop without commentary. This is not meditation. It is the result of a task that fully occupies the available cognitive bandwidth.
Software work can produce the same state. The conditions: the task is slightly above current comfortable ability, the feedback is immediate, and the cost of distraction is visible.
The practical implication: tasks that are too easy or too hard do not produce this state. They produce boredom or anxiety. Calibrating work to the edge of current skill is not just good pedagogy. It is how you get the brain to build the infrastructure.
Further reading
- Juggling and Technology : the cascade as a distributed system and props as AI agent types
- Juggling and Change : drop recovery, incident response, and organisational transformation
- Juggling and the Brain : the full neuroscience deep-dive at The Juggling Company
- Gradient Descent : how machine learning models update iteratively
- Backpropagation : the mechanism behind incremental model learning
- Prometheus : monitoring tools that give you peripheral vision at scale
- The Craft of Software : analogue workshop metaphors for building production systems