simple
Simple — Code for Humans, Not for Art
Code is not for machines. Code is for humans to read, modify, and delete. (That's also why we write it in English, not machine code.) Its primary quality is therefore affordance: how clearly its form (what you see) suggests its usage (how it works) — the way a road sign is instantly readable at 130 km/h by anyone, with no context required.
Don't design an artwork. Design a road sign.
Complexity is a multiplier on bugs and cost, not an additive line item: it makes reading, modifying, and removing code disproportionately more expensive, and the brain spends far more energy parsing a tangled path than a simple, explicit one. It's also insidious — it's introduced gradually, one small addition at a time, so it's easy to become numb to it (the boiling-frog effect) rather than noticing it as it accumulates.
"given choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex" — grugbrain.dev
Core checks
Apply these whenever the situation below comes up — they're independent, use whichever fits.
1. Bugfix quality test
A bugfix that adds a branch (another if, another special case) to patch a symptom is a bad bugfix, even if it "works." A good bugfix simplifies the code or repairs the underlying system so the class of bug can't recur. When proposing or reviewing a fix, actively check: does this fix reduce or increase the number of paths through the code? If it only adds a guard clause around the symptom, say so, and look one level deeper for what's actually broken. (This is the same failure mode Dantotsu's eradication step warns against — a countermeasure dressed up as a permanent fix.)