<p>Flowcharts are useful to make sense of tangled code (i.e., pre-structured programming, see for examples Nijenhuis and Wilf's <a href="https://www2.math.upenn.edu/%7Ewilf/website/CombAlgDownld.html" rel="nofollow noreferrer">&quot;Combinatorial Algorithms&quot;</a> (2nd edition 1978, Academic Press), careful exposition of complex code, written in FORTRAN (when it was still spelled that way). I'm not critisising the programs, they are brilliant examples of well-written code, just to very different standards (and in an area and at a time when short, fast code was at a premium). With today's structured programming languages (a handful of simple control structures you can nest and combine at will), pseudocode of some sort serves much the same purpose.</p>

CC BY-SA 4.0
2021-06-25T14:27:44.877Z
2021-06-25T14:27:44.877Z
vonbrand
<p>Honestly, I would be surprised if this method bore the kind of fruit that you hope for.  While flowcharts seem like a nice way to make ideas more concrete, I contend that they will actually become another level of abstraction that makes the task <em>harder</em> for middle-school students, who are only now making the transition from concrete to abstract thinking.</p>
<p>You're moving from boxes that represent ideas (Scratch, already one layer of abstraction) to boxes that represent arbitrary <em>groups</em> of boxes (now two layers, with fuzzy bottom-layer boundaries designated in the bottom later), and then making macro-decisions using those larger boxes (two layers plus fuzzy boundaries plus a lot of flexible thinking).</p>
<p>In short, I don't think you're going to find a big coding speed-up, or even higher quality output, from the students.  In this regard, it's a trap.</p>
<p>However!  I'm not going to suggest that kids <em>can't</em> use flowcharts.  In fact, I'm not even going to suggest that it's not valuable.  Kids who are beginning to develop abstract thought need to practice that skill-set in order to develop a richer ability to grasp abstractions as an adult.  However, I think that to do it well, you would have to be okay with the idea that it probably won't particularly help the kids with the actual coding tasks themselves, and furthermore decide that it is still worthwhile for other reasons.</p>
<p>If you still wanted to proceed, I would take this backwards approach:</p>
<ol>
<li>Have the kids code in Scratch first, which gets them started with as little abstraction as possible.</li>
<li>Next have them construct flowcharts of what they have done, including a one-sentence description, and a NAME in the box (getting a good NAME can be quite hard)</li>
<li>At this point, they would be better able to manipulate those boxes.  You can ask them to present their flowchart structures (and the accompanying programs, of course!) to the rest of the class.  You can also use the diagrams that they have created to help them if they get stuck (though they may have trouble applying the solutions for all of the reasons listed above).</li>
</ol>
<p>If you want to help them work in the other direction, you can provide a flowchart that works well, and then have them implement it in Scratch.  That can provide support for the concrete -&gt; abstract transition they're undergoing, and also help them learn to move in both directions (Scratch-&gt;flowchart, flowchart-&gt;Scratch).</p>
<p>I wouldn't ask them to work with poorly designed flowcharts (such as the ones that they themselves would make) from the start -- it's not clear to me that you'll get any sort of good result from an unsupported approach like this in a classroom setting.</p>

CC BY-SA 4.0
2021-05-07T20:58:43.690Z
Actually, the Scratch program frame is really almost exactly "structured flow charts".
Buffy
CC BY-SA 4.0
2021-05-07T23:39:38.777Z
@Buffy Yes, which would leave you with a flowchart representing a more detailed flowchart.
Ben I.
CC BY-SA 4.0
2021-05-09T02:38:07.113Z
Thank you for the detailed answer. What I'm hearing is:
1) Unstructured flowcharts (i.e. blocks where you can type anything) may make understanding CT harder, not easier
2) If I do use flowcharts, I should make it clear how those ideas translate to code and vice versa (Students struggling to translate pseudocode to code is the core issue. So the idea of having them play with both directions is really cool.)
Randi W
CC BY-SA 4.0
2021-05-09T11:31:39.423Z
@RandiW I'm no researcher, so this is just my guesswork, informed by my own understandings of cognition and developing brains.  What does CT stand for?  I would agree that if you use flowcharts, direct instruction on how to do it (and perhaps slower initial expectations) would be helpful, and going in both directions might help them grasp a second level of abstraction.
Ben I.
CC BY-SA 4.0
2021-05-09T11:33:23.767Z
@RandiW Once you've actually done it, I hope you'll leave a self-answer to the question with your experiences for future visitors!
Ben I.
CC BY-SA 4.0
2021-05-28T15:11:37.650Z
I don't see a need for pseudo code ether. Pseudo code is only useful to help a novice in expressing an idea it a text based language (before they know this language).
ctrl-alt-delor
CC BY-SA 4.0
2021-05-07T20:49:41.777Z
2021-05-07T20:49:41.777Z
Ben I.
<p>This is a very good and important question. People have doubted the usefulness of flowcharts for a long time, and derided them. But I have two things to say in their defense.</p>
<ol>
<li>It is vital to demonstrate that a correctly structured flowchart and basic pseudocode are one-to-one interchangeable, line by line. Each statement and line in the chart exactly matches one single line of text in the code, with no interpretation or errors possible. If you can write one correctly, you can write the other, and if your flowchart is not structured properly, you will not be able to write the code, at all. This is not magic. It simply means that the properly structured program is neither textual nor visual, and they are both simply &quot;views&quot; of the same underlying structure, which is not composed of either.</li>
</ol>
<p>The underlying structure is what is important, and it is wordless, imageless, and impossible to describe. Fortunately, we have words and diagrams (these days).</p>
<ol start="2">
<li>Every field of human endeavor that I can think of has both textual and visual representations. These are two equally good ways to convey the message. A field without one or the other would have to develop both, or it would not be learnable, teachable, usable. Denying that flowcharts are useful is like saying one of your hands or eyes is not.</li>
</ol>
<p>The message, is not the code. It is not the picture. But, they are interconvertible, at the rate of 8k bytes per image (or more). Use both. Once you show how every line of code matches with a symbol or line on the flowchart, and especially, that the only difference between a While Loop and an If-Then is which end of the line has the arrowhead, you will have shown something that must be learned, but cannot be carried by words alone.</p>

CC BY-SA 4.0
2021-05-28T15:19:47.653Z
I hate flow-charts, but up-voted this. There is a lot of truth. I think what you said may be suitable for college students, but not young students. I would love to see a programming environment where at the click of a button, one could switch between structured-flow-chart, stretch-like, and text. And be able to edit in any one (flow-chart editor would have to constrain to structured. I have seen a flow-chart editor that does this).
ctrl-alt-delor
CC BY-SA 4.0
2021-05-09T22:13:59.687Z
2021-05-09T22:13:59.687Z
Scott Rowe
<p>I'm working with middle school teachers who are teaching a CS class with middle schoolers. The students have a <em>wide</em> range of programming skills, and for some it would be beneficial to offer them an opportunity to plan out their programming work in flowcharts before they step up to implementing them in a language (we're using Scratch btw). <br/>
We used <a href="https://www.canva.com/graphs/flowcharts/" rel="nofollow noreferrer">Canva's flowchart maker</a> and I think that worked decently well, but I'm curious if others have tried and had success with other tools.</p>

CC BY-SA 4.0
2021-05-07T20:01:00.557Z
My advice would be not to use flowcharts at all, especially traditional box and arrow charts. There are too many degrees of freedom in drawing such charts and they lead to extremely poor and convoluted programs. There used to be "structured flow charts" which match the actual nested statement structure of modern programs. David Gries, one of the pioneers, calls them "flaw charts", and I agree.
Buffy
CC BY-SA 4.0
2021-05-07T23:42:49.233Z
Note that flowcharts were created when the primary means of program flow was the goto statement. The arrows in flowcharts are just goto structures. We left all that behind decades ago.
Buffy
CC BY-SA 4.0
2021-05-28T15:07:38.567Z
Yes to what @Buffy said. Scratch (and just about every modern language) is a much higher level (easier) language than flow-charts. Scratch is also visual. If you are doing it because you think it is "the correct way", then note professionals don't use them. They are no use what so ever in understanding a program. However they can be used to write programs for humans (e.g. CPR `check if breathing → breath into mouth` etc). However a good grasp of structured programming is needed to create a good flow-chart.
ctrl-alt-delor
<programming><primary-school>
Resources for flowchart programming for young, new programmers?
# Resources for flowchart programming for young, new programmers?

(Asked by: username_0 on 2021-05-07)

I'm working with middle school teachers who are teaching a CS class with middle schoolers. The students have a *wide* range of programming skills, and for some it would be beneficial to offer them an opportunity to plan out their programming work in flowcharts before they step up to implementing them in a language (we're using Scratch btw).   
We used [Canva's flowchart maker](https://www.canva.com/graphs/flowcharts/) and I think that worked decently well, but I'm curious if others have tried and had success with other tools.

**Tags:** programming, primary-school

> **Comments:**
> **username_1**: My advice would be not to use flowcharts at all, especially traditional box and arrow charts. There are too many degrees of freedom in drawing such charts and they lead to extremely poor and convoluted programs. There used to be "structured flow charts" which match the actual nested statement structure of modern programs. David Gries, one of the pioneers, calls them "flaw charts", and I agree.  
> **username_1**: Note that flowcharts were created when the primary means of program flow was the goto statement. The arrows in flowcharts are just goto structures. We left all that behind decades ago.  
> **username_2**: Yes to what @username_1 said. Scratch (and just about every modern language) is a much higher level (easier) language than flow-charts. Scratch is also visual. If you are doing it because you think it is "the correct way", then note professionals don't use them. They are no use what so ever in understanding a program. However they can be used to write programs for humans (e.g. CPR `check if breathing → breath into mouth` etc). However a good grasp of structured programming is needed to create a good flow-chart.  

---

## 3 answers

### Answer by username_4 on 2021-05-07. Score: 7

Honestly, I would be surprised if this method bore the kind of fruit that you hope for. While flowcharts seem like a nice way to make ideas more concrete, I contend that they will actually become another level of abstraction that makes the task *harder* for middle-school students, who are only now making the transition from concrete to abstract thinking.

You're moving from boxes that represent ideas (Scratch, already one layer of abstraction) to boxes that represent arbitrary *groups* of boxes (now two layers, with fuzzy bottom-layer boundaries designated in the bottom later), and then making macro-decisions using those larger boxes (two layers plus fuzzy boundaries plus a lot of flexible thinking).

In short, I don't think you're going to find a big coding speed-up, or even higher quality output, from the students. In this regard, it's a trap.

However! I'm not going to suggest that kids *can't* use flowcharts. In fact, I'm not even going to suggest that it's not valuable. Kids who are beginning to develop abstract thought need to practice that skill-set in order to develop a richer ability to grasp abstractions as an adult. However, I think that to do it well, you would have to be okay with the idea that it probably won't particularly help the kids with the actual coding tasks themselves, and furthermore decide that it is still worthwhile for other reasons.

If you still wanted to proceed, I would take this backwards approach:

1. Have the kids code in Scratch first, which gets them started with as little abstraction as possible.
2. Next have them construct flowcharts of what they have done, including a one-sentence description, and a NAME in the box (getting a good NAME can be quite hard)
3. At this point, they would be better able to manipulate those boxes. You can ask them to present their flowchart structures (and the accompanying programs, of course!) to the rest of the class. You can also use the diagrams that they have created to help them if they get stuck (though they may have trouble applying the solutions for all of the reasons listed above).

If you want to help them work in the other direction, you can provide a flowchart that works well, and then have them implement it in Scratch. That can provide support for the concrete -> abstract transition they're undergoing, and also help them learn to move in both directions (Scratch->flowchart, flowchart->Scratch).

I wouldn't ask them to work with poorly designed flowcharts (such as the ones that they themselves would make) from the start -- it's not clear to me that you'll get any sort of good result from an unsupported approach like this in a classroom setting.

> **Comments:**
> **username_1**: Actually, the Scratch program frame is really almost exactly "structured flow charts".  
> **username_4**: @username_1 Yes, which would leave you with a flowchart representing a more detailed flowchart.  
> **username_0**: Thank you for the detailed answer. What I'm hearing is: 1) Unstructured flowcharts (i.e. blocks where you can type anything) may make understanding CT harder, not easier 2) If I do use flowcharts, I should make it clear how those ideas translate to code and vice versa (Students struggling to translate pseudocode to code is the core issue. So the idea of having them play with both directions is really cool.)  
> **username_4**: @RandiW I'm no researcher, so this is just my guesswork, informed by my own understandings of cognition and developing brains.  What does CT stand for?  I would agree that if you use flowcharts, direct instruction on how to do it (and perhaps slower initial expectations) would be helpful, and going in both directions might help them grasp a second level of abstraction.  
> **username_4**: @RandiW Once you've actually done it, I hope you'll leave a self-answer to the question with your experiences for future visitors!  
> **username_2**: I don't see a need for pseudo code ether. Pseudo code is only useful to help a novice in expressing an idea it a text based language (before they know this language).  

---

### Answer by username_5 on 2021-05-09. Score: 2

This is a very good and important question. People have doubted the usefulness of flowcharts for a long time, and derided them. But I have two things to say in their defense.

1. It is vital to demonstrate that a correctly structured flowchart and basic pseudocode are one-to-one interchangeable, line by line. Each statement and line in the chart exactly matches one single line of text in the code, with no interpretation or errors possible. If you can write one correctly, you can write the other, and if your flowchart is not structured properly, you will not be able to write the code, at all. This is not magic. It simply means that the properly structured program is neither textual nor visual, and they are both simply "views" of the same underlying structure, which is not composed of either.

The underlying structure is what is important, and it is wordless, imageless, and impossible to describe. Fortunately, we have words and diagrams (these days).

2. Every field of human endeavor that I can think of has both textual and visual representations. These are two equally good ways to convey the message. A field without one or the other would have to develop both, or it would not be learnable, teachable, usable. Denying that flowcharts are useful is like saying one of your hands or eyes is not.

The message, is not the code. It is not the picture. But, they are interconvertible, at the rate of 8k bytes per image (or more). Use both. Once you show how every line of code matches with a symbol or line on the flowchart, and especially, that the only difference between a While Loop and an If-Then is which end of the line has the arrowhead, you will have shown something that must be learned, but cannot be carried by words alone.

> **Comments:**
> **username_2**: I hate flow-charts, but up-voted this. There is a lot of truth. I think what you said may be suitable for college students, but not young students. I would love to see a programming environment where at the click of a button, one could switch between structured-flow-chart, stretch-like, and text. And be able to edit in any one (flow-chart editor would have to constrain to structured. I have seen a flow-chart editor that does this).  

---

### Answer by username_3 on 2021-06-25. Score: 0

Flowcharts are useful to make sense of tangled code (i.e., pre-structured programming, see for examples Nijenhuis and Wilf's ["Combinatorial Algorithms"](https://www2.math.upenn.edu/%7Ewilf/website/CombAlgDownld.html) (2nd edition 1978, Academic Press), careful exposition of complex code, written in FORTRAN (when it was still spelled that way). I'm not critisising the programs, they are brilliant examples of well-written code, just to very different standards (and in an area and at a time when short, fast code was at a premium). With today's structured programming languages (a handful of simple control structures you can nest and combine at will), pseudocode of some sort serves much the same purpose.


---

