In this technical deep-dive, the hosts examine a subtle but critical issue in preference-based resolution functions: the fusion of stable resolution logic with volatile business rules. Using a real-world example of platform preference handling in a show ID resolution function, they explore how implicit assumptions can hide in plain sight and create maintenance friction. The episode covers why extracting business policies into named constants transforms legibility risks into documented decisions, why this matters especially in single-developer codebases, and the principle that code clarity often trumps premature refactoring. Perfect for developers working with multi-instance systems, preference logic, or anyone who's inherited code where the 'why' behind a decision was invisible.

In this episode:

(00:00) The hidden assumption in your show preference logic
(00:38) Why business rules and resolution logic need different change speeds
(01:08) Making implicit assumptions explicit with a single-line change

---
Copy this prompt into Cursor to start implementing:

Based on my podcast episode "Separating Policy from Resolution Logic: Making Implicit Assumptions Explicit", help me:
- Understanding software architecture principles
- Best practices in code organization

Analyze my codebase, identify the relevant files, create a plan, then implement the changes.