On Olympiad physics and engineering intuition
The problem about the magnet
One of the first problems I remember from olympiad training was a magnet falling through a copper tube. You are given the magnet's mass, the tube's conductivity, the geometry, and asked for the terminal velocity. The point of the problem is not to plug numbers into a formula. The formula is the easy part. The point is to see what is happening: the falling magnet induces eddy currents in the copper, those currents resist the motion and bleed the energy off as heat, and the magnet settles into falling slower than it would through empty air. Once that picture is clear, the equation almost writes itself.
I think about that problem a lot when I am debugging systems.
Two ways of knowing
There are two ways of doing physics. The first I would call formula-first: memorize the equations, work out which one applies, and solve. It gets you through textbook problems and falls apart the moment a problem stops looking like the textbook. Olympiad training pushes the other way. The first instruction is not to reach for an equation at all. It is to ask what the system is trying to do, what is standing in its way, and where the energy ends up going.
That habit came with me almost unchanged when I started writing code.
Three places it shows up
- Latency budgets. When I am profiling a hot path, the first question is not which line is slow. It is where the time would even have to be going, whether that is a cache miss, a branch misprediction, or an allocation. I try to estimate before I measure, the same way you would put a number to a physics problem before computing it exactly.
- Distributed systems. A consumer is lagging behind a producer. The textbook answer is "backpressure." The physics answer is closer to the truth: there is a flow rate, there is a downstream resistance, and the queue is the capacitor absorbing the difference between them. Once the system reads as a circuit, the design choices get a lot clearer.
- Training dynamics. When a loss curve flattens earlier than it should, the useful question is not whether the learning rate is wrong. It is what gradient signal the model is not receiving. That has the same shape as asking why the magnet is already falling at terminal velocity.
Where the analogy breaks
I do not want to oversell this. Physics intuition fails me in a few places, and it is worth being honest about them.
- State machines. Conservation laws do not help. Each case just has to be tracked on its own.
- Distributed consensus. The failure modes are combinatorial rather than continuous, and continuity was most of what my intuition was built on.
- Anything involving people. Still working on this one.
Why I keep going back
What olympiad physics gave me was not a technique. It was a habit of looking at the system before trying to solve it, and that has been more useful to me than any single algorithm class or framework. It is also the part of how I think that I most want to protect as time goes on. The easy default, after a few years of writing code, is to recognize the pattern and skip the look.
I try not to skip the look.