I've found that I can't talk at all. I record myself to track down any inefficiencies and I decided to talk during some sessions.
I miss words, I use wrong words. Sometimes I completely go silent when working out a tricky part.
My hypothesis is that the implementation part should be 2nd nature and I should be able to talk through it. So I'm probably switching from notepad to editor too quickly.
My language skill (as my "1st nature") completely sucks. I feel impossible to explain the solution any problem more than 2200 rated. Sometimes I try to explain something and end up messing it up. Don't know if your problem is same as mine.
I'd say explaining the solution is something I can do, once it finally works.
Of course, the explanation of solution does not mean I can explain how I got there. For some problems it can be a systemic mathematical symbolic manipulation. This symbolic manipulation can be hard to follow if I omit steps that are obvious to me, but if I really try to go step-by-step it is fine.
For other solutions it's like a rabbit-out-of-the-hat moment where I just come up with the invariant/approach that works.
But my problem is that while I'm problem solving, my internal thinking renders me incapable to talk coherently. I either talk like I'm having a brain stroke or I just use incorrect words. I feel that these attempts to talk about it also impact my ability to fully solve it.
I'd compare it to playing an instrument and singing at the same time. At least 1 thing needs to be 2nd nature and fully out of focus, so that I can do the other. This might imply I either don't know how to sing, or don't know how to really play the guitar, I'm working at a lower level and have to practice more to have the whole thing chunked.
For problem solving, it's like I still cannot just type out the solution that's compressed in my brain, or I am thinking consciously too much about the solution so I cannot talk about what I'm coding.
It's definitely worth ironing out. I practiced this with some easier problems until it was second nature.
For example:
https://mirror.codeforces.com/contest/1909/problem/B
Let's try some small numbers: 1 is pointless.
Try 2: if it fails numbers are all even or all odd. Write that down
With some luck, you might realize that by trying 4 right after, there are at most 2 mod values. Write down
A way to visualize the worst case would be Write down
10101010 Write down
notice how when you slide a window of length 4 it does not change the amount of 1s in it, staying permanently at 2. Write down
If all numbers are equal mod 4 then:
1000100010001 Write down
Sliding a window of 8 across it does not exceed 2 ones. Write down
The logic can be extended all the way to 2^60. Then it is guaranteed that a solution is found. write down
Write EVERYTHING down. Once you are able to write coherently while solving you will be able to talk about it too.
You also might notice an increase in learning speed :)
.
Do you mean when you code the solution or when trying to figure it out? I don't know exactly why would you need to talk while coding a solution? I might leave some comments regarding how tuples are used or if there are very many big steps I might at times leave a short comment like "now search for X that has Y condition" so I don't end up forgetting to do that. When I think a solution I usually have a paper on hand + write in a .txt file (depends on how I'm viewing the problem, it's easier to draw a graph on paper) some ideas or some self-made samples to better understand the problem. However I'm not super sure how much this helps, I've started doing it somewhat recently.
For example, I can talk about writing certain parts of the solution, I can get automatic subtitles and track how long it took me, for example, to code a particular Dijkstra or DFS or binary lifting or similar parts.
Then I can easily see if I am improving over time or if there's something I forgot.
Of course, I currently can just look at all of my previous solutions and get a feel for how much I remember, but I find it useful to just see annotated timestamps and the duration.
I agree with you, I have no idea if I should just type and brainstorm in the editor, or if I should use the pencil. I've had the privilege of seeing many red coders live in competition and interestingly they wrote quite a lot on paper and then coded it all up after paper is done.
I'm already a bit older than usual competitive programmer, so I'm just trying to not bruteforce it like most kids can do with all of their free time.
I find it helpful to formulate the solution in my head, not as abstract ideas but as a clear sequence of steps. I also try to logically / mathematically prove to myself why the solution would work. It does take a while, and in contests it does slow me down significantly. I do that intentionally. While intuition and making leaps in logic intuitively can make me solve faster, it also often leads to inaccurate conclusions. Or even worse, correct solutions, but I cannot explain to myself how certain corner cases get handled by that solution. Thinking about implementation details early on is also a slippery slope, as we may end up spending too much mental effort in the nitty gritties of a wrong solution. I encourage you to try practicing restraint before you jump to the editor. To spend time explaining to yourself why something works, finding confidence in your own approach, before you implement it.