<p>I believe that the core issue you're dealing with is that programming is too enjoyable, which makes outlining a program/writing pseudocode not interesting.  It is a tough sell because in the time that students could be understanding a problem, they could be doing it (which is more fun).  You need to demonstrate the value that pseudocode provides and what kind of issues it can avoid.  This is easier to show off in big programs.</p>
<p>When I assign big projects and students come up with their own implementation that shows they didn't think about the problem, I ask them to start over.  This is my compromise for not forcing them to write pseudocode.  The idea behind starting over is they now understand the problem and the pitfalls well enough to start coding for real.  <strong>In a way, all that code they wrote, was just a harder version of pseudocode.</strong></p>
<p>I'm not sure what level you're teaching, but towards the end of AP CSA, the majority of my students have started a program over.  They are resistant in the moment, but the following year, almost all of them gave thanks.  Knowing how to start over is not the same as learning to write pseudocode, but both result in a better understanding of the problem.</p>

CC BY-SA 4.0
2020-09-19T22:05:11.317Z
Interesting comment, "Programming is too enjoyable." Sometimes they are wrestling with a problem and really feel quite confused, which I wouldn't call enjoyable, but the only way they see to start work is to dive in and write code, because pseudo-code is too abstract for them to think of. And I think it takes time to be ready to think in the abstract so I don't want to push that too much.
composerMike
CC BY-SA 4.0
2020-09-18T22:10:55.023Z
2020-09-28T03:01:44.183Z
2020-09-28T03:01:44.183Z
guitarcat
<p>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;.</p>
<p>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 <code>for</code> 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 <code>for</code> loops and <code>break</code> statements. That's the first thing, the immediate goal of the lesson.</p>
<p>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.</p>

CC BY-SA 4.0
2020-09-28T21:23:22.760Z
Thanks for this. I'm a little confused why you and Steve have objected to calling it high-level - okay so let's call it chunking. https://en.wikipedia.org/wiki/Chunking_(psychology) What you call the mental model as well as the English description involve chunking - combining several details in a single thought. That's a form of abstraction and a step toward grasping larger and larger abstractions. I call "abstraction" high-level, but maybe I'm using it wrong. You use the words "big picture" and a mental picture "all or most of the way through" which also sound high-level to me. But thanks!
composerMike
CC BY-SA 4.0
2020-09-28T21:29:36.527Z
I like "programming by perturbation" - I see that a lot. I've actually seen it more in self-taught adults who come to me to learn to program right. I'm sure it's in a lot of your young students, too.
composerMike
CC BY-SA 4.0
2020-10-01T04:38:06.533Z
I didn't mean that pseudocode doesn't require thinking at a high level. I meant that for me, the immediate goal is the planning. The practice with thinking more abstractly is just a bonus at this point.
Dave R
CC BY-SA 4.0
2020-09-28T05:36:58.720Z
2020-09-28T05:36:58.720Z
Dave R
<p>Warning : I am not a teacher of any kind, just a developer and I will tell about by personal feelings/experience</p>
<p>For me when I write in pseudocode I write in my native language (not English but I am sure it applies for all peoples native languages).</p>
<p>My native language is the language I use everyday since I was born, this is a language I know really well.</p>
<p>When writing directly in a programming language you use a language that you don't know entirely and which sometimes (for low level languages like C or C++) forces you to think low level because there are specific rules.</p>
<p>When I was a student I always wanted to write code directly and never think beforehand. After acquiring some experience (especially with big/ complex programs), I understood that thinking of the code in an abstract manner helps a lot.</p>
<p>I think forcing to write in English might be good but it might be better for them to discover that by themselves. I they try to make complex programs they will have to write in English to understand what they are doing and then they will continue doing it.</p>

CC BY-SA 4.0
2020-09-20T19:47:55.690Z
I understand your point about allowing them to discover it for themselves, but I think sometimes students need to be pushed a little to start doing something that maybe they wouldn't do on their own. They are ready - they are ready to do something new and make progress even if it's uncomfortable.
composerMike
CC BY-SA 4.0
2020-09-18T08:46:00.547Z
2020-09-18T08:46:00.547Z
f222
<p>I'm a freelance tutor working with high school students, giving them programming assignments in languages like Python, Java, C++, and others.</p>
<p>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.)</p>
<p>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.</p>
<p>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.</p>
<p>To give an example, let's consider Euler 46, &quot;Goldbach's other conjection&quot; <a href="https://projecteuler.net/problem=46" rel="nofollow noreferrer">https://projecteuler.net/problem=46</a></p>
<p>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</p>
<pre><code>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 ???
        }
    }   
}
</code></pre>
<p>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 <code>break</code> without having considered ahead of time how that will play out.</p>
<p>What I'm trying to get them to do is write pseudocode like this:</p>
<pre><code>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
</code></pre>
<p>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.</p>
<pre><code>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
</code></pre>
<p>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).</p>
<p>Then there's documentation. The difference between something low level like</p>
<pre><code>// set i to 0. increment i and stop when it's n 
for (int i = 0; i &lt; n; i++) {
</code></pre>
<p>and higher level like</p>
<pre><code>// loop over possible test values (i)
for (int i = 0; i &lt; n; i++) {
</code></pre>
<p>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?</p>

CC BY-SA 4.0
2020-09-22T10:57:32.033Z
Communication skills are invaluable, but I've never understood the value of "pseudocode". In practice, you have to know a programming language to fathom it at all, and it's almost invariably some awkward pidgin of an existing language plus English comments, just vaguer but certainly not "higher level".
Steve
CC BY-SA 4.0
2020-09-23T19:46:53.233Z
Pseudo-code may sometimes be useless, but it offers an *opportunity* to work with abstraction and cognitive chunking -- https://en.wikipedia.org/wiki/Chunking_(psychology) -- that is what I mean by higher level and that's what I aim for my students to understand.
composerMike
CC BY-SA 4.0
2020-09-23T20:35:23.027Z
I'd like to see more evidence of the link between pseudocode and "chunking". For example, you ask for "loop over possible test values (i)", well isn't that just called a "for each" or "for all" loop? The problem is that you have to understand a real programming language to understand what a "for each" loop is. You also have to understand a programming language to even understand the tenets of block structures (like the nested loops you refer to). This approach of using pseudocode (which lacks the specification and rigour of real code) simply doesn't smell right to me at all.
Steve
CC BY-SA 4.0
2020-09-23T21:08:50.210Z
I never said you don't have to understand a real programming language. Pseudo-code comes after concrete experience. The example here is a minor abstraction (doing away with the need to think about limits) but it's only a tiny beginning of what's possible. I value abstraction and chunking in all of their applications - which apply to any higher-level design of code, as well as writing, composing music, playing chess, etc.
composerMike
CC BY-SA 4.0
2020-09-24T11:16:04.270Z
I wonder whether your students wouldn't ask questions like the following. Firstly, what exactly are the formal features of this "pseudocode"? Is it block structures (and indenting or so-called 'horizontal layout' techniques) with the control statements (and the kind of block) stated freeform in English? A language must be shared - pidgins are less expressive, less widely spoken, and more ambiguous than established languages they are formed from. It's possible your students lack confidence in the usefulness of the pidgin, or lack a clear understanding of the concepts it employs. (1/2)
Steve
CC BY-SA 4.0
2020-09-24T11:24:38.483Z
Secondly, what exactly does "higher level" mean? Does it mean stating complex operations in fewer English words? If so, do you need to build their English vocabulary and communication skills? Are you providing a proper foundational understanding of these "high level" things (as opposed to skirting the specifics, on which an understanding would rest)? And again, do your students have confidence that this vocabulary is industry standard or widely spoken, or that (if you have devised it yourself) that it is credible and sufficiently systematic to be useful and worth spending time to learn? (2/2)
Steve
CC BY-SA 4.0
2020-09-24T21:45:22.003Z
These are good questions. I think I'll work out some of the answers with experience teaching in this way. Right now I don't give them assignments to write pseudo-code on their own - it's a facilitated experience and I give them a rationale for every decision I make, so I think they have a chance to develop a concrete understanding. As far as I can tell they find it useful, just a stretch of their understanding, but something that makes writing code easier afterward. Good question re standard vocab - my understanding is that I'm teaching them mental processes which (1/1)
composerMike
CC BY-SA 4.0
2020-09-24T21:51:50.520Z
professional programmers use (not just vocab) which I have inferred from contact with other professionals - often mental processes aren't spoken about, just assumed that you pick up if you work as a coder. I think some programmers flame out because they don't figure out chunking and abstraction on their own. Finally, yes much of this is my style and I do want to avoid the hubris of thinking everyone is better off thinking like me - time will tell what works.
composerMike
CC BY-SA 4.0
2020-09-25T00:02:03.340Z
If you're interested, I recorded a session today with his permission (taking a student through Euler 38 in C++). We use psedo-code and English to flesh out an understanding. https://youtu.be/jIquuSSdRSw This is an hour long and pretty slow for a third party observer, but if you are interested Steve, I really respect your desire to make this process concrete and would value your feedback.
composerMike
CC BY-SA 4.0
2020-09-25T20:08:33.827Z
thanks for this, I think that's given me a much clearer impression of the situation, and much to digest! I didn't watch the video in a completely linear fashion, as I had to go off and find out what Euler was, what a "pandigital" was, and so forth. Spontaneously, whilst parsing the statement of the problem, I found myself engaging in my mind in the production of what you've called "pseudocode", and in particular analysing what the limits of iteration would be. The first thing I note is that this is not what I considered "pseudocode" - rather, I conducted an inner monologue...
Steve
CC BY-SA 4.0
2020-09-25T20:25:43.427Z
...in English (and also manipulated visual imagery), and if I were to write down key points and abbreviated conclusions of that monologue, it would look similar to what you're calling "pseudocode". In my view, this is not "pseudocode" intended for communication, it's part of one's own mental working. Essentially what you're saying to students is "before writing code, you're going to have to spend time reasoning about what form the algorithm should take, and that reasoning will take place (and be noted down) predominantly and most conveniently in English"...
Steve
CC BY-SA 4.0
2020-09-25T20:45:28.927Z
...So what are you really teaching your students here? In my view, it's the need to engage in analysis, and to somehow record at least some key points of that analysis, because one will refer back to what is recorded as an adjunct to one's own internal memory. And I definitely agree with you that this is an important technique to learn. The other point I made was about whether this "pseudocode" is "high-level" - in my view it isn't, it's actually somewhat wooly and very narrowly focused on recognising the need for, and working out the detailed range for, iteration.
Steve
CC BY-SA 4.0
2020-09-26T21:13:04.760Z
Thanks for your comments. I think I know what you mean about "high-level" - it's certainly not high-level compared to a UML diagram of a large system. However, I think it's still a form of abstraction. I teach the general problem solving strategy of "solve a simpler problem first" - helping them to see how to analyze the problem in portions without needing to grasp the whole first. This is related to any kind of analysis or high-level design I think. Concretely that means that any way of making analysis easier will be an inspiration to the way they analyze at all levels....
composerMike
CC BY-SA 4.0
2020-09-26T21:16:39.297Z
... I don't if you have encountered this, but many of our students today have ingrained the idea that hard problems should feel hard and difficult to work through, so they don't look for an easier way. And, thinking with words and images is a skill that takes practice, and without guidance they may spend all their practice time making that harder than necessary. Certainly I did. It was only with pedagogic mentors as an adult that I started "looking for the easier way"
composerMike
CC BY-SA 4.0
2020-09-28T05:47:54.510Z
That last comment of yours deserve to be embossed and framed @composerMike!! «students today have the ingrained idea that hard problems should feel hard and difficult; so don't look for easier ways» Dunno if you find this useful : Not spectacular code but in the direction (I feel) you wish your students to go http://melaniemkwon.github.io/blog/2017/09/09/haskell-goldbach.html
Rushi
<pseudo-code><documentation>
How useful is English (pseudocode and documentation) in aiding understanding?
# How useful is English (pseudocode and documentation) in aiding understanding?

(Asked by: username_0 on 2020-09-17)

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, "Goldbach's other conjection" 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 < ???; n++)
{
    for (int i = 0; i < ???; i++) 
    {
        for (int j = 0; j < ???; 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 < 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 < n; i++) {

and higher level like
// loop over possible test values (i)
for (int i = 0; i < 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. "Chunking" 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?

**Tags:** pseudo-code, documentation

> **Comments:**
> **username_1**: Communication skills are invaluable, but I've never understood the value of "pseudocode". In practice, you have to know a programming language to fathom it at all, and it's almost invariably some awkward pidgin of an existing language plus English comments, just vaguer but certainly not "higher level".  
> **username_0**: Pseudo-code may sometimes be useless, but it offers an *opportunity* to work with abstraction and cognitive chunking -- https://en.wikipedia.org/wiki/Chunking_(psychology) -- that is what I mean by higher level and that's what I aim for my students to understand.  
> **username_1**: I'd like to see more evidence of the link between pseudocode and "chunking". For example, you ask for "loop over possible test values (i)", well isn't that just called a "for each" or "for all" loop? The problem is that you have to understand a real programming language to understand what a "for each" loop is. You also have to understand a programming language to even understand the tenets of block structures (like the nested loops you refer to). This approach of using pseudocode (which lacks the specification and rigour of real code) simply doesn't smell right to me at all.  
> **username_0**: I never said you don't have to understand a real programming language. Pseudo-code comes after concrete experience. The example here is a minor abstraction (doing away with the need to think about limits) but it's only a tiny beginning of what's possible. I value abstraction and chunking in all of their applications - which apply to any higher-level design of code, as well as writing, composing music, playing chess, etc.  
> **username_1**: I wonder whether your students wouldn't ask questions like the following. Firstly, what exactly are the formal features of this "pseudocode"? Is it block structures (and indenting or so-called 'horizontal layout' techniques) with the control statements (and the kind of block) stated freeform in English? A language must be shared - pidgins are less expressive, less widely spoken, and more ambiguous than established languages they are formed from. It's possible your students lack confidence in the usefulness of the pidgin, or lack a clear understanding of the concepts it employs. (1/2)  
> **username_1**: Secondly, what exactly does "higher level" mean? Does it mean stating complex operations in fewer English words? If so, do you need to build their English vocabulary and communication skills? Are you providing a proper foundational understanding of these "high level" things (as opposed to skirting the specifics, on which an understanding would rest)? And again, do your students have confidence that this vocabulary is industry standard or widely spoken, or that (if you have devised it yourself) that it is credible and sufficiently systematic to be useful and worth spending time to learn? (2/2)  
> **username_0**: These are good questions. I think I'll work out some of the answers with experience teaching in this way. Right now I don't give them assignments to write pseudo-code on their own - it's a facilitated experience and I give them a rationale for every decision I make, so I think they have a chance to develop a concrete understanding. As far as I can tell they find it useful, just a stretch of their understanding, but something that makes writing code easier afterward. Good question re standard vocab - my understanding is that I'm teaching them mental processes which (1/1)  
> **username_0**: professional programmers use (not just vocab) which I have inferred from contact with other professionals - often mental processes aren't spoken about, just assumed that you pick up if you work as a coder. I think some programmers flame out because they don't figure out chunking and abstraction on their own. Finally, yes much of this is my style and I do want to avoid the hubris of thinking everyone is better off thinking like me - time will tell what works.  
> **username_0**: If you're interested, I recorded a session today with his permission (taking a student through Euler 38 in C++). We use psedo-code and English to flesh out an understanding. https://youtu.be/jIquuSSdRSw This is an hour long and pretty slow for a third party observer, but if you are interested username_1, I really respect your desire to make this process concrete and would value your feedback.  
> **username_1**: thanks for this, I think that's given me a much clearer impression of the situation, and much to digest! I didn't watch the video in a completely linear fashion, as I had to go off and find out what Euler was, what a "pandigital" was, and so forth. Spontaneously, whilst parsing the statement of the problem, I found myself engaging in my mind in the production of what you've called "pseudocode", and in particular analysing what the limits of iteration would be. The first thing I note is that this is not what I considered "pseudocode" - rather, I conducted an inner monologue...  
> **username_1**: ...in English (and also manipulated visual imagery), and if I were to write down key points and abbreviated conclusions of that monologue, it would look similar to what you're calling "pseudocode". In my view, this is not "pseudocode" intended for communication, it's part of one's own mental working. Essentially what you're saying to students is "before writing code, you're going to have to spend time reasoning about what form the algorithm should take, and that reasoning will take place (and be noted down) predominantly and most conveniently in English"...  
> **username_1**: ...So what are you really teaching your students here? In my view, it's the need to engage in analysis, and to somehow record at least some key points of that analysis, because one will refer back to what is recorded as an adjunct to one's own internal memory. And I definitely agree with you that this is an important technique to learn. The other point I made was about whether this "pseudocode" is "high-level" - in my view it isn't, it's actually somewhat wooly and very narrowly focused on recognising the need for, and working out the detailed range for, iteration.  
> **username_0**: Thanks for your comments. I think I know what you mean about "high-level" - it's certainly not high-level compared to a UML diagram of a large system. However, I think it's still a form of abstraction. I teach the general problem solving strategy of "solve a simpler problem first" - helping them to see how to analyze the problem in portions without needing to grasp the whole first. This is related to any kind of analysis or high-level design I think. Concretely that means that any way of making analysis easier will be an inspiration to the way they analyze at all levels....  
> **username_0**: ... I don't if you have encountered this, but many of our students today have ingrained the idea that hard problems should feel hard and difficult to work through, so they don't look for an easier way. And, thinking with words and images is a skill that takes practice, and without guidance they may spend all their practice time making that harder than necessary. Certainly I did. It was only with pedagogic mentors as an adult that I started "looking for the easier way"  
> **username_2**: That last comment of yours deserve to be embossed and framed @username_0!! «students today have the ingrained idea that hard problems should feel hard and difficult; so don't look for easier ways» Dunno if you find this useful : Not spectacular code but in the direction (I feel) you wish your students to go http://melaniemkwon.github.io/blog/2017/09/09/haskell-goldbach.html  

---

## 3 answers

### Answer by username_3 on 2020-09-18. Score: 3 | Accepted answer

I believe that the core issue you're dealing with is that programming is too enjoyable, which makes outlining a program/writing pseudocode not interesting. It is a tough sell because in the time that students could be understanding a problem, they could be doing it (which is more fun). You need to demonstrate the value that pseudocode provides and what kind of issues it can avoid. This is easier to show off in big programs.

When I assign big projects and students come up with their own implementation that shows they didn't think about the problem, I ask them to start over. This is my compromise for not forcing them to write pseudocode. The idea behind starting over is they now understand the problem and the pitfalls well enough to start coding for real. **In a way, all that code they wrote, was just a harder version of pseudocode.**

I'm not sure what level you're teaching, but towards the end of AP CSA, the majority of my students have started a program over. They are resistant in the moment, but the following year, almost all of them gave thanks. Knowing how to start over is not the same as learning to write pseudocode, but both result in a better understanding of the problem.

> **Comments:**
> **username_0**: Interesting comment, "Programming is too enjoyable." Sometimes they are wrestling with a problem and really feel quite confused, which I wouldn't call enjoyable, but the only way they see to start work is to dive in and write code, because pseudo-code is too abstract for them to think of. And I think it takes time to be ready to think in the abstract so I don't want to push that too much.  

---

### Answer by username_4 on 2020-09-28. Score: 4

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 "dive in" 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 "programming by perturbation", 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 "works".

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.

> **Comments:**
> **username_0**: Thanks for this. I'm a little confused why you and username_1 have objected to calling it high-level - okay so let's call it chunking. https://en.wikipedia.org/wiki/Chunking_(psychology) What you call the mental model as well as the English description involve chunking - combining several details in a single thought. That's a form of abstraction and a step toward grasping larger and larger abstractions. I call "abstraction" high-level, but maybe I'm using it wrong. You use the words "big picture" and a mental picture "all or most of the way through" which also sound high-level to me. But thanks!  
> **username_0**: I like "programming by perturbation" - I see that a lot. I've actually seen it more in self-taught adults who come to me to learn to program right. I'm sure it's in a lot of your young students, too.  
> **username_4**: I didn't mean that pseudocode doesn't require thinking at a high level. I meant that for me, the immediate goal is the planning. The practice with thinking more abstractly is just a bonus at this point.  

---

### Answer by username_5 on 2020-09-18. Score: 2

Warning : I am not a teacher of any kind, just a developer and I will tell about by personal feelings/experience

For me when I write in pseudocode I write in my native language (not English but I am sure it applies for all peoples native languages).

My native language is the language I use everyday since I was born, this is a language I know really well.

When writing directly in a programming language you use a language that you don't know entirely and which sometimes (for low level languages like C or C++) forces you to think low level because there are specific rules.

When I was a student I always wanted to write code directly and never think beforehand. After acquiring some experience (especially with big/ complex programs), I understood that thinking of the code in an abstract manner helps a lot.

I think forcing to write in English might be good but it might be better for them to discover that by themselves. I they try to make complex programs they will have to write in English to understand what they are doing and then they will continue doing it.

> **Comments:**
> **username_0**: I understand your point about allowing them to discover it for themselves, but I think sometimes students need to be pushed a little to start doing something that maybe they wouldn't do on their own. They are ready - they are ready to do something new and make progress even if it's uncomfortable.  

---

