been thinking about this lately. I have a service at work where the code is genuinely ugly (bad naming, some duplicated logic, not fun to read) but it's been running reliably for two years and never caused an incident.
separately there's a cleaner-looking module that's caused three rollbacks this quarter because of some assumptions that weren't obvious from reading the code.
I've started keeping a rough mental model of "messy but stable" vs "clean but fragile" for different parts of our stack, and it's actually changing how I prioritize code review. curious if anyone formalizes this in any way or if it mostly just lives in someone's head
[link] [留言]
