The request that looked like a one-line change
A feature request came in that, on paper, sounded almost too simple to plan: "Let therapists open a chart, click on an objective, and drill down into its targets and steps."
Technically, it was basically a one-liner. The data model already had everything — targets, steps, per-session scores, all wired up. The charting library was already in the codebase. The click target was one attribute away from being clickable. If I'd measured the task by "how many files change," I'd have said a day, maybe less.
But "technically simple" and "correct on the first try" are unrelated properties of a feature, and this one was entirely UX-shaped. How do you lay out an unknown number of targets side by side without it collapsing into a wall of tiny charts? Does the section stay pinned while you scroll past it, or does that just eat the screen? What does a chart need to say — not show, say — for a therapist scanning five kids' worth of sessions to actually notice the thing that matters?
None of that gets decided correctly on paper. It gets decided by looking at it, clicking it, and reacting honestly to what's in front of you — which is exactly the kind of feedback that's cheap to get on a static HTML file and expensive to get on a real component tree with real state, real i18n keys, and a real test suite attached to it.
