Coworker spent a week rewriting a function in Rust "for performance." The function ran once per request. Took 2ms. The database query next to it? 400ms.
Optimized the wrong thing by 200x margin.
Ask a developer what's slow. They'll guess wrong 90% of the time.
Developer intuition:
"The loop is slow" → Actually: 0.1ms
"String concat is slow" → Actually: 0.01ms
"That function is fine" → Actually: 3000ms (N+1 query inside)
We're terrible at this because performance is counterintuitive. The code that looks expensive often isn't. The innocent-looking line is calling a database 100 times.
Measure first. Optimize what the profiler shows you.
Most web apps:
Your for-loop isn't the problem. Your missing index is.
One index. 600x improvement. Zero code changes.
Rewrote a search feature last month. Original: O(n²) nested loops. 10,000 items took 8 seconds.
8 seconds → 50ms. No amount of micro-optimization would fix the original. The algorithm was wrong.
1. Make it work
2. Write benchmarks
3. Profile under realistic load
4. Find the actual bottleneck
5. Fix it
6. Stop when fast enough
Step 6 is crucial. "Fast enough" is a real target. Don't optimize past it.
Ship first. Profile later. Optimize the 48%, not the 1%.
You can't think your way to performance. You have to measure your way there.
— blanho
UUIDs aren't always the answer. Here's when they hurt more than help.
When direct data transfer becomes unwieldy, add a layer of indirection. Netflix learned this the hard way.
You have 10 million saved searches. A new item comes in. How do you find all matches without running 10 million queries?
# Profiler output:
# 48% time: database query (users)
# 31% time: external API call
# 12% time: JSON serialization
# 9% time: everything else
# What devs want to optimize: "everything else"
# What matters: that 48% query-- Before: 1200ms
SELECT * FROM orders WHERE user_id = 123;
-- After adding index: 2ms
CREATE INDEX idx_orders_user_id ON orders(user_id);# Before: O(n²)
for item in items:
for other in items:
if matches(item, other):
results.append((item, other))
# After: O(n) with hash lookup
lookup = {item.key: item for item in items}
for item in items:
if item.target_key in lookup:
results.append((item, lookup[item.target_key]))