I've found myself lately repeatedly saying "Let's tackle it when it becomes an problem"

I know earlier in my career I would've found that an incredibly frustrating response from a technical manager. We know what the problem is, why not solve it now? However in my old age (I'm still in my 20s.. just) I've come around on it. As a developer we're taught to identify how the solution would work alongside any of the risks, edge case scenarios, and potential problems. We want to write good code that performs as we expect. It's a noble cause. But it's not that simple.

All software projects are competing against two things. A release date and the amount of developer hours we have until then. Naturally, we tend to think about the entire solution. As in, writing our good, noble code. However, given the amount of developer hours we have. Is it worth it? Is there somewhere our time would be better spent? Is this edge case likely to happen? Does this need to happen now, or could we do it later?

Which will lead you to -

"Let's tackle it when it becomes an problem"

Because it probably won't become one.

Programming is an art. Software delivery is an art too. Part of the mastery is understanding where you can cut corners in order to meet expectations. Ideally we have all the time in the world to ensure we write the best code possible. However we don't live in an ideal world, we live in this one instead.

Using your intuition along with your experience you can make a judgement call on the risk of not doing the work now and instead prioritising it when it is necessary. i.e, tackling it when it becomes a problem. I've been surprised since I've shifted into using that phrase repeatedly, because it turns out. It doesn't become a problem very often.

For reference, you should still be sanitising your inputs. But how many users will notice that your scroll wheel is actually a fixed list?