On reading other people's code

Most of the trouble I see in production comes from boundary cases someone promised would never happen. The code is fine. The plan is fine. The promise is what ages badly.

I split a 4000-line file into 12 smaller ones this week. The smaller files weren't actually easier to understand. The 4000-line file was a problem of structure, not of length.

Every time I revisit a project after six months, I find at least one place where past-me wrote a comment that present-me has now stopped trusting. Comments rot faster than code.

I keep a small log of decisions in a text file. Not architectural — just small ones. "Picked X over Y because Z." Future me reads it more than I thought he would.

Latency budgets work better than latency targets. Targets are aspirational. Budgets force you to delete features when you go over.

The fastest debugging trick I've learned is to write out, in one sentence, what the system is supposed to be doing. Half the time I notice the bug while writing the sentence.