Skip to main content

Welcome, the Hub connects all projects

Integrating STEM+C

All Topics for this Forum

Topic: "How do we transition from general problem solving to CT?"

Topic Posts

Topic started by: Katie Rich on 3/7/16

In the "Computational Thinking in Elementary School" thread, we discussed the the differences between general problem-solving strategies (like breaking a problem into smaller parts) and strategies that are specific to computational thinking (like breaking a problem into parts that can each be addressed by a different algorithm or previously developed computational solution). There seemed to be general agreement with the idea that general problem-solving ideas used in many academic subjects have synergy with CT, but in order to be CT, users of the strategies must be applying the strategy to a computational solution.

(Please feel free to protest if you don't agree with the above!)

I walked away from that conversation feeling that developing CT curricula in elementary school will likely involve finding ways to start with the general problem solving strategies kids already use, making the relationship to CT clear to teachers, and defining pathways from the general strategies to CT-specific activities, eventually making the relationship to CT clear to students.

What are some ways we might facilitate this transition?

This archived topic is open to the public.

restart conversation
This topic has 4 posts, showing all.

different problems, or just different strategies?

posted by: Katie Rich on 3/7/2016 1:19 pm

I've specifically been considering the benefits and costs of making the transition by introducing a computational solution to a problem that has already been solved by other means, or, alternatively, by introducing a related problem that is better suited to a computational solution.

An example of the former might be something like this:
1. Students in elementary school practice writing really clear directions for someone else to follow. (A good practice in general, applicable to a number of pursuits.)

2. A bit later, students do the same exercise, but a teacher or someone else provides feedback by doing exactly what the directions say and nothing more (imitating the actions of an agent that does only what it is explicitly directed to do).

3. Even later, students learn that a computer is such an agent, and learn the specifics of how to write directions for a computer to do the same task.

An example of the latter might be something like this (thanks to Irene Lee for sharing a similar example and inspiring this one):

1. Students find the shortest path from one location to another in a context in which there is only a finite number of possibilities (say, 5). They solve the problem by trying each one.

2. Later, they solve a similar problem where there are too many possibilities to reasonably try them all, and discuss ways they could eliminate possibilities without trying every single one.

3. Still later, they consider how Google maps might choose a route from one location to another and learn how computers can be used to sort through thousands of possibilities quickly.

I think the benefit of the first approach is that is makes it clear that computing is a strategy that can be considered alongside others. However, in some ways it seems to minimize the power of computing and doesn't to provide much insight into why you might choose a computing strategy. The latter makes this clearer.

Is there a place for both of these kinds of progressions?

Multiple options

posted by: Trevor Takayama on 3/17/2016 8:38 pm

I think there is always room for multiple way of solving a problem or looking at any issue/problem.

I find that most elementary school students along with adults do not use logic. Maybe it takes a job or personality that tends to think logically for people to develop that type of mindset. Regardless, it should be taught.

Students are taught basic cause and effect, but they should develop that into various CT functions. It will greatly help them improve their step-by-step directions and improve their logical thinking.

The /lack/ of causality in a digital world

posted by: Paul Goldenberg on 3/21/2016 2:09 pm

Sixty years ago, kids who took apart a typewriter might well have been able to see how all the parts worked together to get the effect of the fully-functioning machine. But even if they did not, they got a part of the picture clear. Pressing on this part physically moves that part, which pulls on the third part, which.... A mechanical calculator was an even more interesting puzzle, but one could at least see action A causing reaction B. Taking it apart gave you more information about how it works than you had before you took it apart.

That's not true with today's keyboards and calculators. Take them apart and you get no new information. They're magic.

I think students are not "taught" cause and effect except in the most trivial ways that they already sort of know -- actions (social, physical) have consequences -- but not in any deeper sense of trains of causality. That is part of the hope behind CCSS Mathematical Practice #3, "construct viable arguments and critique the reasoning of others." A "viable argument" is not just a claim, or even a discussion, but a chain of "A, therefore B, whereupon C, resulting in D" causality. It's not physical causality, of course, but the kind of logical connectedness that you mentioned. In mathematics, that's what we ask from proof --- as much (or more) to establish the mechanism by which something is true than to establish the fact that it is true. The call, in the early 90s, for "reduced attention to proof" felt, to me, very anti-causality, and I'm glad it's gone.

While I'd like to see kinds have hands-on experiences with causality, building things (e.g., with the Lego gears and other moving parts that interact in clearly causal ways), I also think that programming is a good virtual complement. It's not a substitute, but it has capabilities that mechanical parts do not. Writing a program is an exercise in causality, a lot like proof. This sequence of steps leads inevitably to that outcome. Even a buggy program --- one that leads to an unexpected or unwanted outcome --- is a proof that that sequence of steps has that specific outcome.

To me, programming in some suitable language --- one that lets a child focus on the meaning of the steps and not the semi-colons --- seems a particularly constructive way to build logic. It's certainly true to any notion of CT that I've seen discussed.

inside the black box

posted by: Katie Rich on 3/22/2016 5:23 pm

Thanks, Trevor and Paul. This is very interesting. I hadn't thought specifically about cause and effect as it relates to problem-solving or CT, nor had I ever given consideration to the difference between simple action --> consequence relationships and longer chains of reasoning.

In other (non-CS-related) work with mathematics and technology, I have often made the argument that there's no reason kids need to know how to divide by hand, for example, before they use a calculator to divide. I think exploring what happens when you use the division key on a calculator can be helpful to understanding the meaning of division -- more helpful, when approached the way, than memorizing and applying the steps of an algorithm. In that sense, I didn't mind that calculators were sort of a black box.

However, what's really inside the black box is not a paper-and-pencil algorithm. It's a computer program. And I think kids examining that, rather than the paper and pencil alternative, has better potential to enrich mathematical learning.

I'm not sure what this means for how to approach integration, but it's always helpful to have new ways to think about things. Much to ponder.