There is a benefit to writing that first line of code during the planning phase. Sometimes a problem that at first seems difficult to think about, maybe because it’s too abstract, becomes simpler and not all that scary after a first attempt at writing it.
Akin to The Pragmatic Programmer’s tracer bullets idea, you can use code as a resource during the design phase of your solution, or use it instead of trying to explain something verbally.
You must, however, write these pseudo-tracer-bullets with at least the intention of throwing them away once they’ve served their purpose, which is to help you understand more intimately your ideas and their aptitude to solve a specific problem. In the book, tracer bullets aren’t suggested as throwaway code:
Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production code has. It simply is not fully functional. 
What I’m proposing here is that you can do the same, but with the sole intention of understanding or explaining a concept better, and in a less constrained way, with throwaway code.
More often than I’d like, I find myself struggling to put in words some architectural decision, or to understand in conversation a design that a colleague is explaining to me. In those cases, I try to remember to always put it down in code, and maybe, as it happens with pictures, that piece of code is worth a thousand words.
David Thomas and Andrew Hunt, The Pragmatic Programmer, 20th Anniversary Edition, Addison-Wesley, 2020.