Totally agree, how I see it, it's related to taking time to sharpen your axe.
Having a defined flow that gives you quick feedback quick and doesn't get in the way.
I you are writing, then you'd be using an app that you can quickly do what you want, e.g shortcuts for bold, vim/emacs motions, that "things-not-getting-in-the-way" state is what leads to flow state, in my opinion.
Muscle memory is action for free, then you can focus on thinking deeper.
Same happens with coding, although is more complex and can take time to land in a workflow with tools that allow you to move quick, I'm talking about, logs, debugger (if needed), hot reloading of the website, unit test that run fast, knowing who to ask or where to go for finding references, good documentation, good database client, having prepared shortcuts to everything ... and so on.
I think it would be could if people would share their flow-tools with different tech stacks, could benefit a lot of us that have some % of this done, but not 100% there yet.
The energy threshold for adding a new unit test to the suite and a new row to the docs are vital for it to be done.
If I need to install pandoc to test compile a doc change before i submit it for code review with 3 other maintainers, id rather keep my note or useful screenshot to myself.
If i need to create a c binding of my function so that pytest can run it through 50 rows of cryptic CMake, I'd rather do happy testing locally and submit it as a "trust me bro".
Good and fast international tooling matters massively for good software. And it all comes back to speed and iteration loop.
On top of that, slow meticulous work can then be done. 100% test coverage, detailed uml diagrams describing the system, and functional safety risk analysis matrix documents.
So speed and slowness supplement in different levels of analysis.