**When designing a system, don’t use e.g. “lack of yes” as the “no” condition.** When designing a system, avoid utilizing the “lack of signal received” as an indicator. It is a much more robust practice to give clear and explicit signals that NECESSARILY MUST have been created intentionally than it is to utilize some implicit signal like “well, he didn’t tell me there was an issue so I assume it’s fine”. [[Signals Require Contrast]]. This can be manifest in writing an API or a sufficiently complicated function returning an object. Tack on a “status” flag with the resultant, and have it set explicitly. Utilizing a Lack of Signal as a signal is an [[Error Trap]]. # Possible Exception One of the tenets of my [[PDW|Data Journal]] in its [[spreadsheet]]-based implementation is that I am **explicit** about blanks in columns like "workout" mean **NO** workout occurred. This goes against the rule inherited by this note, but the blank space is automatically created. It's not a case of there isn't even an empty spot. There's a spot where the signal definitely would be if it did exist. Basically - if there's an obvious place where the signal definitely would be, then _perhaps_ it's okay. Still, it would be probably better to have an explicit "didn't workout" value. **** # More ## Source ## Related - [[Error Trap]]