How useful is English (pseudocode and documentation) in aiding understanding? I'm a freelance tutor working with high school students, giving them programming assignments in languages like Python, Java, C++, and others.
In recent months I've seen the value of using English - getting them to write documentation and also to write down rough drafts of their algorithms in pseudocode. I'm wondering what other teachers do with this. (I'll give an example with an Euler problem.)
The goal is to get them to think at a high level. Typically they like to dive into code. It's not concrete to them if they aren't writing code. I get it, developing a higher-level understanding is something that takes time. But I think I need to push it a little - they are just avoiding pseuocode and documentation past the point when they are really ready to use it.
One obstacle is their general writing abilities. The students who don't write well in any context, like English class, find it the hardest to write documentation and pseudocode.
To give an example, let's consider Euler 46, &quot;Goldbach's other conjection&quot; https://projecteuler.net/problem=46
This project involves testing different ways of adding squares and primes, in some kind of nested for loop. Typically they want to start out with details like
for (int n = 0; n &lt; ???; n++)
{
    for (int i = 0; i &lt; ???; i++) 
    {
        for (int j = 0; j &lt; ???; j++)
        {
            ??? generate square and prime S and prime P ???
            if (2 * s + p == n)
                break; // and do what then ???
        }
    }   
}

Where I have put question marks is where they aren't sure what to put. But they begin wrestling with each place I have put question marks right away. That means they are struggling with low level details right away before they really understand the gestalt of the problem. Also they will throw in a break without having considered ahead of time how that will play out.
What I'm trying to get them to do is write pseudocode like this:
For every N, an odd composition number we are testing, in some range
    For every prime P &lt; N
        if N - P is not twice a square, we found an exception. print or mark it

Of course this is a big leap, so I guide them to it gradually. (The benefits of working as a tutor and not a classroom teacher.) When they think at a high level, they can also see choices available to them. like maybe that pseudocode could be modified to be made more effcient.
For every N, an odd composition number we are testing, in some range
    For every value 2 * S where S is a square
        if N - 2*S is not a prime, we found an exception. print or mark it

They can reflect on the difference long before they have wrestled with the details of for loops. They can think about how they might efficiently test if a number is prime. Maybe they've seen before this idea of generating a hash set of primes and think about whether that's faster than trying to find out if a number is a square (which requires a sqrt operation).
Then there's documentation. The difference between something low level like
// set i to 0. increment i and stop when it's n 
for (int i = 0; i &lt; n; i++) {

and higher level like
// loop over possible test values (i)
for (int i = 0; i &lt; n; i++) {

What I'm looking for from the answers is whether other teachers have found it useful to bring English into helping them develop higher-level understanding. &quot;Chunking&quot; concepts for example (thinking with high-level or abstract concepts). And how successful is this? Does it depend on a student's ability to use English in the first place?
Funny, I came here to look for advice on getting students to write pseudocode, because mine struggle so much to do it. So here is why I want them to do it. If I set the activity up properly, and they engage with it, then they will really be planning their program before they start to write it. There are different reasons people like to &quot;dive in&quot; to code. Sometimes an entire solution just occurs to you and there's no reason not to start right in. But sometimes, it's because you don't know any other way. Just start typing and see what pops out. This leads to &quot;programming by perturbation&quot;, where you arrive somewhere kind of close to a solution by a mix of chance and lucky guesses, and just kinda change symbols here and there until it &quot;works&quot;.
I've tried assigning flowcharts over the years, but I think pseudocode works better for my teaching style. I can explain more clearly what I want the students to try to do. They still resist, and because the little details (like for loop fiddling) are still more enticing to think about than the big picture of how the program will do its job, I still have to nudge them and encourage them to keep the birds-eye view. So for me (and perhaps this also addresses other comments on your question), it's not so much that pseudocode is really a great way to think deeply or at a high level. It's that insisting on a natural-language description of the problem and its solution seems to be an effective path toward my goal. And what is the goal? To make sure that the learners have a mental model of what their program should do—all or most of the way through, not just the first step, and perhaps even anticipating some tricky edge cases—before they start nesting up a bunch of for loops and break statements. That's the first thing, the immediate goal of the lesson.
Now to really answer your question, my experience suggests that learners can learn the most when they explain their solutions to others. This is not really possible to do, unless you've practiced the kind of communication we're talking about. You don't explain your program by reading the listing verbatim. You have to paraphrase it so that its parts correspond to your mental model, because the model is ultimately what you are conveying to the listener. In fact, I'm much less interested in whether students can produce programs that solve the problems I pose than in their thought processes along the way, which they can only convey to me by explanations in the natural languages we share.