Jakub Kasztalski was prototyping a management sim about public restrooms when he hit a wall: the simulation worked, but balancing it was impossible. His variables were correct for the code and useless for the person turning the dials. The problem, he argues, was naming conventions — not the system.

The fix in each case is the same: invert the formula so the variable is the thing a designer can actually picture.

  • Patience drains by a “Patience Depletion Rate” — unbalanceable. Rewritten as WaitTime, the seconds before a patron storms off.
  • Radiators spread “Heat Strength” — how far can someone stand from one? Rewritten as HeatRadius, with falloff as a percentage of that radius.
  • Weapons lose “Durability per use” — arbitrary. Rewritten as UsesBeforeBroken, so the config number is the number of swings.

Three rules fall out of that:

  • Keep direction consistent — high is always good. Rename Fatigue to Energy, ItemUseCount to ItemDurability.
  • Keep the math linear when accuracy doesn’t matter. Use 1/Distance instead of inverse-square, so doubling distance halves the effect rather than quartering it.
  • Pick units designers think in. A 50–90% comfort band reads at a glance; 65F–85F does not.

The conversion cost is real but one-time and lives in code. The mental math it removes is repeated on every single tweak, forever. Written in 2016, the advice lands harder now — these are exactly the names an LLM reads when you ask it to reason about your systems.