Teaching Critical Thinking

Question

In answers to a previous question, a few people suggested intro programming with true novices might not be the best place to introduce critical thinking/planning skills for programs. To me, intro programming is the perfect place - many of these skills relate to the ideas of breaking problems down (which tie in nicely with loops), abstraction (e.g., methods/classes), and so on. Particularly with many students only taking intro programming as part of a degree for an unrelated field (e.g., physics, math) in the hopes of being able to do some application-based work, I feel that students would benefit from these skills for such projects.

I am certainly open to be convinced on this topic! Should these skills be explicitly taught in a CS curriculum? If so, where?

Answer 1

First, Critical Thinking is a deep concept and in a first course only simple aspects of it can be taught. To explore the depth of it you need to have context and a novice, by definition, has little of that. See Wikipedia for a start on understanding how broad and deep Critical Thinking really is.

To me, the most important question to be answered by Critical Thinking is "What should be built?" (and what not built). But a novice has no basis on which to answer such a question. They have enough to do to try to understand what can be built at the start, so you can only give a glimpse of the deeper questions then.

I would suggest that any true education explore Critical Thinking in many ways and in many courses - philosophy, history, .... And that later in the CS curriculum the topic be taken up, again in several courses/classes to explore its complete depth.

However, the detail in your question seems to indicate that you are more interested in Deep Thinking rather than Critical Thinking as such. I'm a big believer in teaching problem decomposition and abstraction from the first days. My courses delay if and while constructs for as long as I can manage while the students think about abstraction and polymorphism. I don't always do it, but prefer to teach recursive thinking before loops and polymorphism before selection. That is true even in a course in Java. It doesn't require Scheme.

But some aspects of critical thinking are useful to novices. For example, the idea that if what you are doing isn't working, then do something different. Also "Ask for help" when you are stuck. "Don't make assumptions" is another good idea that can be taught fairly early. "Test your assumptions."

Ultimately you want them to use evidence based decision making, of course rather than wishful or magical thinking, but that, as I said above, requires context and some "seasoning." Novices are naturally focused on the "how" rather than the "what" - especially the "what is appropriate" and "what is important."

Answer 2

I'm going to echo ctrl-alt-delor's comment and say that as one of the answerers on the original question, my understanding was not that "a few people suggested intro programming with true novices might not be the best place to introduce critical thinking/planning skills for programs". I don't think anybody suggested that. In fact I'm pretty sure that 100% of the people on this site would agree that critical thinking and problem solving are very important lessons to learn, especially with computer science. (And maybe even that computer science is a great way to teach general problem solving, but I'll digress.)

critical thinking/planning skills for programs

I think the source of our misunderstanding is that we haven't really defined what this actually means. Your original question mentioned having students come up with a glossary of classes and functions they might find useful, and drawing diagrams. Imho, neither one of these is very good at teaching critical thinking or planning skills.

I agree with your goal of teaching problem solving, and maybe planning depending on what you mean. What I disagree with is the approach of using glossaries and diagrams to teach these things.

Instead, I think the best way to teach problem solving and planning is by teaching the process of breaking a problem down into smaller steps and then taking those steps on one at a time. I've written this tutorial on the topic, and I try to encourage this process (as opposed to just dumping syntax) in my answers on Stack Overflow.

I don't think diagrams or glossaries really help with this. I think the only way to learn it is by working through the process. You might do this by live-coding a few examples of taking a large problem and breaking it down. I would teach using Processing, so my examples would be visual:

Our goal is to draw a garden scene with grass, flowers, and a bird that flies around. First let's try to break that up into smaller pieces. Can we create a simple program that just displays the grass part? (Which we can further split into drawing a single blade of grass, then a small patch, then the whole screen.) Separately from that, can we create a program that just displays one flower? (Again, that might be further split into drawing a stem, the center of the flower, the petals, etc.) Now can we just get a circle flying around?

The idea would be to actually walk through the process of taking a big amorphous problem and breaking it down into smaller actionable steps, and then writing code to accomplish each of those steps one at a time.

Spending any time on diagrams at this stage is, imho, wasted time. Students don't have a big picture yet, and diagrams aren't appropriate for the scale we're talking about at this level. Similarly, forcing students to come up with their own glossary honestly sounds pretty painful, and isn't how things work in the real world. I think that's what the answerers were saying.

Answer 3

I am mostly in agreement with @kevinWorkman on this (I don't disagree with anything, there is just one thing he was silent on, that I think is very important).

• Yes break down the problem.
• Yes do one thing at a time.
• Yes test often.

In addition:

Test first

1. Decide what the test is before you code.
2. Run the test to check that it fails.
3. Write some code.
4. Run the test to check it passes.
5. Iterate as required.

Just in time planning

As part of doing one thing at a time.

Our goal is to draw a garden scene with grass, flowers, and a bird that flies around. First let's try to break that up into smaller pieces. Can we create a simple program that just displays the grass part? (Which we can further split into drawing a single blade of grass,

STOP Planning

Time to code (Time to write a test, then code):

Using test first, write the code to draw a blade of grass.

STOP Coding

Time to plan

then a small patch [of grass],

STOP Planning

Time to code

Summary

• The process uses «alternating repetition» of planning / coding. Do not do any more planning than needed (do not plan ahead). Do not write any code that is not planned.
• Coding uses «strong boundaries» test around code, with «alternating repetition» of fail/pass in the tests. That is test surrounds the code, and is of a similar scale as the code. The tests alternate between pass and fail. Do write any tests that are not needed (do not test ahead). Do not write any code that does not have a test that has failed.

The properties in «» are from Christopher Alexander's book “The nature of order”. They are what patterns are made of. see https://cseducators.stackexchange.com/a/2821/204 for a list of all 15.