I still do. Of course dabbling into REPL-based solutions in my youth might have influenced that. For me it is crucial to always have have the code in some comp

I still do. Of course dabbling into REPL-based solutions in my youth might have influenced that. For me it is crucial to always have have the code in some compile-able and testable state. I iteratively work towards the simplest, most naive solution that gets the job done. After that it is refactoring time and I form it into a proper solution. The reason I do so is because only after having coded the naive solution, I have an concrete and proven correct understanding of the task and can pick the appropriate abstractions. I always see colleagues with an less iterative style use premature-abstractions and over engineering on the basis of "we might need it" instead of knowing. I do invest some time into thinking about the right data structure though. (Not much about algorithms, as they mostly follow from the data structures anyway.) Also if I code a well understood problem, I might use a more top down approach. (Not a critique of your workflow, just wanted to share mine.)