> The largest impact is sometimes asking simple questions (how are you going to handle X?) which leads to not building something.

Which is why I teach new people to have that loop in your head and not start pounding the keyboard at high velocity. The people who find programming to be akin to fast typing show very interesting equivalence with LLMs; fully write/remove/write/remove etc of not very well written code.

Mhh for me it is always a combination of the two. I like making a good high level plan, but for certain problems it is better to make the plan as you go, because you can't fully understand the shape of the problem and the potential solutions as you start. Sure maybe that means your first code sucks and is a prototype that should be replaced, but if you are aware of that and don't pretend otherwise I don't see why this wouldn't be okay.

When I managed software for a large corporate, I kept a box of pencils on my desk.

For around 1/2 the information requests that came through the department (always very important, we need the info now, it will save/make big dollars) the obvious answer was "Work it out from the info you already have. You've got a calculator and spreadsheet - would you like a pencil?"

Better to avoid the system handling X than having multiple special cases bulking up the systems, most of which only get used once in a blue moon. No one knows the special cases/programs are there, or what actually do. Even if well documented, no one spends the time required to know what's available. So most of those special features are actually waste of time.