# Resources for flowchart programming for young, new programmers?

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 and I think that worked decently well, but I'm curious if others have tried and had success with other tools.

• 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. May 7, 2021 at 20:01
• 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. May 7, 2021 at 23:42
• 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. May 28, 2021 at 15:07

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.

• Actually, the Scratch program frame is really almost exactly "structured flow charts". May 7, 2021 at 20:58
• @Buffy Yes, which would leave you with a flowchart representing a more detailed flowchart.
– Ben I.
May 7, 2021 at 23:39
• 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.) May 9, 2021 at 2:38
• @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.
May 9, 2021 at 11:31
• @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.
May 9, 2021 at 11:33

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).

1. 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.

• 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). May 28, 2021 at 15:19

Flowcharts are useful to make sense of tangled code (i.e., pre-structured programming, see for examples Nijenhuis and Wilf's "Combinatorial Algorithms" (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.