Make It Work → Right → Fast — Profile Before You Optimize

Make it work, make it right, make it fast — in that order

Kent Beck's sequence is a discipline, not a slogan. Correctness first; speed last and only where measured. The opposite — optimizing while building, by intuition — is what Knuth meant by "premature optimization is the root of all evil": you add complexity and bugs to speed up code that wasn't the bottleneck.

The performance method: measure, don't guess

1. Establish a baseline & a target — "no number = no goal" (from the approach lesson).
2. Profile to find the hotspot. Almost always the time is concentrated (Pareto: ~80% in ~20% of the code, often a single function or query). Flame graphs (Brendan Gregg) show it at a glance.
3. Fix the biggest contributor — and re-measure. The win must show up in the number, not your belief.
4. Repeat until you hit the target, then stop.

Why fixing the non-bottleneck is wasted — Amdahl's Law: if a part is 6% of runtime, making it infinitely fast saves at most 6%. The diagram's 78% DB query is the only thing worth touching first; add the index, not a faster renderer.

Reading resource health: the USE method

For any resource (CPU, memory, disk, network), check Utilization, Saturation (queueing), and Errors. A saturated, queueing resource is your bottleneck — this is how you find which resource to profile before diving into code.

Pitfalls

• Optimizing by intuition — engineers are famously wrong about where time goes; profile.
• No baseline — you can't tell if a change helped.
• Micro-optimizing the 6% — Amdahl caps the payoff; find the 78% first.
• Optimizing before it's correct — fast wrong code is still wrong.

Takeaways

• Work → right → fast, in order; speed only where measured.
• Profile to the hotspot (Pareto); fix the biggest, re-measure; Amdahl caps non-bottleneck wins.
• USE (Utilization/Saturation/Errors) finds the bottlenecked resource first.

---

Re-authored for this guide; profile/loop diagram hand-authored as SVG. Follows Beck, Knuth, and Brendan Gregg's performance methodology (USE method, flame graphs). See also: How to Approach a Problem, Tail Latency, (Concurrency) Amdahl's Law, How a Query Executes.

I just read a lesson on **Make It Work → Right → Fast — Profile Before You Optimize** (System Design) and want to truly understand it. Explain Make It Work → Right → Fast — Profile Before You Optimize from first principles using ONE vivid real-world analogy and a visual mental model — draw it as ASCII art or a clear step-by-step diagram — with a concrete example using real numbers. Then ask me one question to check I got the mental picture, and wait for my reply. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Teach me **Make It Work → Right → Fast — Profile Before You Optimize** interactively. Ask me ONE guiding question at a time, wait for my answer, and adapt to my confusion — build the idea with me step by step instead of explaining it all at once. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Quiz me on **Make It Work → Right → Fast — Profile Before You Optimize** with 5 questions, easy to tricky, ONE at a time. Tell me if each answer is right; at the end, explain clearly what I got wrong and why. If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.

Help me remember **Make It Work → Right → Fast — Profile Before You Optimize** for the long term: give the one-sentence intuition, a memorable hook/mnemonic, a tiny worked example, and 3 active-recall flashcards (Q -> A). If you're unsure or a claim isn't standard, say so and reason from first principles instead of guessing.