measure-don't-guess (profile before optimize)

Imagine your program feels slow and you are sure you know why — it must be that big loop, or that recursive function. So you spend a day rewriting it, and the program is exactly as slow as before. The real cost was somewhere else entirely. This is the everyday trap that the rule measure-don't-guess exists to prevent: do not trust your intuition about where time goes, find out.

Concretely the rule says: before changing any code to make it faster, run a tool that tells you where the time actually goes, then change the part that the measurement says is expensive, then measure again to confirm the change helped. The tool that tells you where time goes is called a profiler, and the activity is called profiling. The reason your intuition is unreliable is that a modern CPU, its caches, the memory system, and the operating system interact in ways no human tracks in their head; the line of code that looks innocent (one array access) can be the one waiting on memory for hundreds of cycles, while the scary-looking arithmetic runs nearly for free.

It matters because optimization effort is itself expensive — it costs your time and usually makes the code harder to read and more bug-prone — so you want to spend it only where it pays off. A common professional discipline is: get it correct first, measure, and only then optimize the small fraction of the code (often called the hot path) that the profiler shows dominates the run time. The honest caveat: measuring badly is worse than not measuring, because a misleading number gives false confidence — so the rule is really measure WELL, which the rest of this field is about.