Things broken on purpose
Daniel C. · Nov 11
I write smaller commits than I used to. The commits are uglier in isolation and much easier to read in sequence.
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.
There's a kind of premature optimization that comes from imagining a future team. "What if someone needs to swap this out?" Often, no one does.
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.
Most retry logic I've removed turned out to be hiding a real bug. The retries made the failure invisible, and the bug compounded for months in the background.
← back to index