List what breaks and design for it.
What it really is
On the surface, Designing for edge cases can look like a single technique you either know or you don't. The real skill underneath is starting from the user's real problem and turning it into something worth building — and that's the part that actually transfers from one situation to the next. Here it shows up as a concrete, repeatable habit: list what breaks and design for it.
Why it matters
Building the right thing beats building the thing right. A Delta finds the problem worth solving before writing the code.
What good looks like
- You separate the literal request from the underlying job.
- You can name who the user is and what they're really trying to do.
- You prioritize by impact, not by what's easy.
Common trap
Taking the feature request at face value and skipping the "why."
How to practice
The rep: List what breaks and design for it.
Do it on a real problem, not a hypothetical — under the kind of pressure where it's tempting to skip. Land it and you earn the Edge Case Hunter badge. Repeat it until it stops feeling like a technique and starts feeling like instinct.