Friday, April 03, 2015

What’s Your Student’s Problem Solving Strategy?

I ran into this Developer’s problem solving sequence list via twitter yesterday.

  1. Google 
  2. Coworkers
  3. StackOverflow
  4. RTFM
  5. Think

My students seem to use something similar. Although they leave out reading the fine manual and for the most part StackOverflow. It probably looks something like:

  1. Mr. Thompson
  2. Students
  3. Google
  4. Think

I’m really trying to get them to stop always asking me for the answers. That is the easy way out. WP_20150402_001I’d rather they ask their peers or even search the Internet. I want them to learn how to learn. Of course what I really want them to do first is to think. I’ve even got the sign!

Now not all of them think as the last thing. I have a good number of students who are really good thinkers and problem solvers. Several of them are good at asking peers or doing Internet searches. But for every student who figures it out quickly, looks things up, and asks for a direction rather than a complete answer there is usually a student who starts off with “what do I do?” or “where do I start?” Those are the students who really need a teacher.

Some students are great at learning on their own. Some students are great at paying attentions, learning a concept and understanding how to apply it. I suspect many of those students would do just fine with a MOOC or an online tutorial or even a book. Remember books? But some students need more. Some students really need a human teacher.

Some students get to high school having had everything spelled out for them in nice step by step instructions that tested their ability to follow instructions but to how to problem solve or think critically. They are used to having a problem already broken down into predigested pieces. It’s not their fault.

So I spend some time talking to students about the parts. What are they? How can we break them down to smaller parts? And then, and only then, how do we do it in code? If I can get them there I figure that is success.

at

7 comments:

  1. Unknown8:15 AM

    I have the same issue. With some students, I've gotten frustrated with them because their questions are just about error messages that they should figure out themselves. Often when I can't get to them in time, they end up figuring it out, and then I say, see, you don't need me as much as you think.

    ReplyDelete
  2. Steve and Jen9:06 AM

    Yes, early in the year students would often call me over with an error. My response is always, did you set a breakpoint, step through your code and see why this is happening. Sometimes they need help stepping through. But I am seeing them debugging on their own more and asking for help less, so that is progress

    ReplyDelete
  3. Steve and Jen12:54 PM

    Alfred, you just gave me a great idea. I think I am going to make a poster for my class that reads.

    Student Problem Solving Strategy

    1. Think
    2. Breakpoint an debug
    3. Think
    4. Ask another student
    5. Think
    6. Google
    7. Think
    8. Ask Mr. King
    9. Think

    ReplyDelete
  4. Garth2:00 PM

    I have solved the "Ask Mr. Flint" issue. I give the assignment, we discuss the assignment for issues or strategies, i then leave the room. My office is 5 feet away so I can hear what is going on but that 5 feet makes a big difference on how they approach the problem. Out of sight, out of mind. It also helps that two of the six in the senior Java class are very independent problem solvers. In the sophomore class only one of the three is independent. I cannot abandon them quite so much.

    ReplyDelete
  5. Mike Zamansky9:14 AM

    Rubber duck debugging

    ReplyDelete
  6. Alfred C Thompson II2:33 PM

    Rubber duck debugging http://en.wikipedia.org/wiki/Rubber_duck_debugging

    ReplyDelete
  7. K Decker1:56 PM

    It's not a bad idea to give them a little structure for the "Thinking" step. For example, the Program By Design "Design Recipe" is a two-dimensional approach to design thinking: it comprises both a process (set of steps) and step variations based on the type of data your function consumes and/or produces. It is a systematic way to address the "blank page syndrome", i.e., "how do I go from a problem description to a working program?" for small projects (students eventually learn larger scale software engineering processes).

    Each step is objectively gradable, so you can test their "thinking" even before the code step. In fact, getting TAs (or yourself!) to NOT debug code (instead, Socratically check that they followed all the previous DR steps) can be hard (especially when you can see the error yourself :-) )

    Felleisen often points out these steps are really fairly generic problem solving strategy (i.e., you could use them to design a science experiment or write a journalism news article) but they try to focus attention on "formalizing", or making parts of a problem more concrete, in a step by step manner.

    ReplyDelete