Completely agree. My best decisions are not made on my feet, and I have often been responsible for difficult technical tasks. I also prefer to "communicate my thinking" in the form of readable, well-tested code that can be verified by a machine.
If that code is unsatisfactory for some reason, I'd rather figure that out after writing it, based on concrete evidence, than during an upfront design meeting with folks who likely won't be doing the actual work, but often feel the need to impose themselves in arbitrary ways. When a team focuses on excellent communication through writing, I find less planning and verbalizing is necessary, and a lot more gets done.
As a partial aside, one of my greatest annoyances when starting a new job is when after being grilled for technical skills during the interview, they walk you in to a messy, amateur codebase, where many of the ideals discussed during the interview clearly haven't been applied, but no one seems to acknowledge it. This has happened to me repeatedly, enough so that when these sorts of questions come up during the interview, I mentally start preparing for the disappointment. People sometimes seem to take more pride in trying to rattle candidates than they do in building anything admirable. Luckily, there are many fine places to work where the team can be honest with itself and with candidates. I don't really care about the current state of projects when I'm starting; I don't mind being a janitor (except in extreme cases). Just don't start our relationship off with a load of BS. I feel like this is such an elephant in the industry. A lot of our code is bad, real bad, but we can't admit it.