Resources for flowchart programming for young, new programmers?

Question

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.

Answer 1

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.

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

Answer 3

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.