Every developer has been there: opening a pull request and encountering something like `deployFeature(flag, true, false, true)` or `updateSettings(user, true, false, true, false)`. The code works perfectly. The problem is, nobody—including the author—can remember what those booleans mean without jumping into the function definition and scrolling around to figure it out.

This is called boolean blindness in some circles, though the terminology matters less than the pain itself. When writing the function, passing raw booleans feels convenient: `createUser(user, isAdmin, sendWelcomeEmail)` reads fine at definition time. That convenience gets paid for later by anyone reading the call site, including the author two weeks later. TypeScript doesn't help much here—it confirms the values are booleans without explaining what they represent.

The fix is straightforward: use an options object instead. Rather than `createUser(user, true, false)`, write `createUser(user, { isAdmin: true, sendWelcomeEmail: false })`. Now the code is self-documenting. When a boolean starts representing a different action entirely—like `createUser(user, true)` meaning "create an admin"—it's better to split into `createAdminUser(user)` and `createRegularUser(user)`. These tiny readability improvements compound across a codebase, turning constant context-switching into smooth sailing.