[100011_100001]

If it's a small meeting I will say, "Give me a moment, I'm thinking". Even then it's faster thinking than I would like.

If I'm forced to answer something, the more significant it is the more of a caveat I will make. Something along the lines of "Right now, I think X would be fine, I'm worried that Y might cause problems. I will look at the code and let you know".

Then I always make sure to reply in an email to say for our conversation on X, I looked at Y, I found this, and also realized that Z will be affected. I'm basically buying time, the key, at least from my perspective is always going back and answering properly.

[au8er]

From my experience, saying "I'm thinking" actually makes it worse. Instead of thinking for a response, I internally start to panic (mainly thinking whether I have considered everything and the response is correct). After a few seconds of "thinking", I eventually give a response that is no different to my knee-jerk reaction.

I do find replying with an email to be extremely helpful. Even if the response is not correct, it does show you have put in the effort to reflect on the meeting after it has finished.

[magicalhippo]

> After a few seconds of "thinking", I eventually give a response that is no different to my knee-jerk reaction.

In interviews with Magnus Carlsen and the other top players, they all seem to say the same thing: the big difference between a short game (bullet/blitz) and a long game is that they'll have more time to verify the move in the long game. They don't spend more time finding the move.

I find this resonates with me. Very often the instinctive solution I come up with on the spot is often a very good solution and requires only minor tweaks.

> I internally start to panic (mainly thinking whether I have considered everything and the response is correct)

I just add a caveat: "I think X is a good solution but I have not had time to consider all the edge cases, so I will have to verify and come back to you" or similar.

Or, if the problem is complicated I'll just say that: "There are a lot of complexities/edge cases to consider here, I need to think more thoroughly about this. I'll get back to you later".

[8n4vidtmkvmk]

It's usually easy to iterate the possible solutions. Widdling them down to the best one is the hard part. Still, it helps to write them out. And if you're in a meeting, you should maybe just stop there and then write an AI to rule the bad ones out. (Which of course we could have done without a meeting, but I digress)

[8n4vidtmkvmk]

> I will look at the code and let you know

I used to do that. Now I just say "Look into X, Y, and Z, I think they might pose a problem" and let them do the research. I can't solve everything for everybody. If it's not my project, I'll give you some pointers, but not hours of my time.