Rob Pike's 5 Rules of Programming

The Rules

1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places. Don't guess — prove it.
2. Measure. Don't tune for speed until you've measured. Even then, don't unless one part of the code overwhelms the rest.
3. Fancy algorithms are slow when n is small, and n is usually small. Big-O doesn't matter when constants dominate. Use Rule 2 first.
4. Fancy algorithms are buggier than simple ones. Use simple algorithms and simple data structures.
5. Data dominates. Choose the right data structures and the algorithms become self-evident. "Write stupid code that uses smart objects."

How to Apply

Before Any Optimization

Stop and ask these questions in order:

1. "Have I measured?" — If no, measure first. Any optimization without measurement data is premature. Use whatever profiling tool is natural for the project's language and ecosystem.
2. "Does one part overwhelm the rest?" — If no single area dominates, there is nothing worth optimizing. Small improvements spread across many areas rarely matter.
3. "What's n?" — If n is small (and it usually is), the simple O(n²) approach likely beats the clever O(n log n) one due to constants, cache behavior, and implementation complexity.
4. "Is this a data structure problem?" — Before changing the algorithm, consider whether a different data structure makes the problem trivial. The right structure often eliminates the need for a clever algorithm entirely.
5. "Is the added complexity worth it?" — Simple code that is 10% slower is almost always preferable to clever code that is fragile and hard to maintain.

Anti-Patterns to Block

When you catch yourself or the user doing any of these, STOP and redirect:

When Optimization IS Justified

Proceed with optimization only when ALL of these are true:

• You have measurement data showing a specific bottleneck
• That bottleneck dominates overall runtime (not just 5-10% of it)
• The proposed fix is the simplest change that addresses the measured problem
• You will re-measure after the change to confirm improvement