Courage to Attack Difficult Questions In a recent blog post Eugene Wallingford says that when teaching:

I frequently pose a problem for them to work on for a few minutes before we look at a solution, or several candidates, as a group. All too often some students look at the problem, think it's too difficult, and then just sit there waiting for me to show them the answer. This approach often results in them feeling two kinds of failure: they didn't solve the problem, and they don't even appreciate the solution when they see it.

There is a double problem here, The first is that some students don't attempt to solve a difficult problem - giving up early. This leads to the second problem of not recognizing the beauty of the solution once they see it.
How can we encourage/enforce/demand/cajole students into making a good faith effort on a difficult problem without making them feel defeated at the end?
Often the exercises we give students have a learning objective that is more important than the actual solution to the problem. Learning is to be valued over solutions in a teaching environment. But students don't always see that and can be led to think of themselves as failures even when they work hard toward a solution (Authenticity Bias). We need to find ways to avoid that outcome while we encourage hard thinking.
The big idea here is that the effort to find a solution, even if it goes down an unprofitable path, will lead to learning. The practice of &quot;stretching your brain muscle&quot; is wort pursuing.
One Pedagogical Pattern was originally named Kobayashi Maru after a training exercise that was central to a certain Star Trek episode. In this pattern, the idea is to give students an impossible task to give them practice in very hard problems, possibly requiring orthogonal thinking. (The pattern was later re-named to Mission Impossible). That isn't exactly the same issue here, where we are looking to encourage deep thinking on deep but solvable problems.

This issue is not just about programming. It can be anything. For example a complex database design issue or a complex retrieval. Or in Compilers, some optimization issue that needs to run fast. Lots of opportunities for hard problems in any class.
I think this is a pretty common problem, especially for novice programmers. They're given an assignment and don't know how to start- in fact, they don't even know what it's asking!

I don't think this is due to a lack of "courage" - it's because they don't have the framework required to start breaking problems down yet.

I think step one is to normalize this a bit, and specifically mention that this is a common way to feel. Then walk them through the process of getting over that initial hurdle. What behavior do you want them to exhibit? Model that behavior for them.

I try to encourage people to break their problem down into smaller steps and take those steps on one at a time. There are a lot of approaches here, including:


Restate the problem in your own words.
Break the problem down into logical sub-steps.
Identify your input and output.
Think about how you'd do this without a computer, with a piece of paper and a pencil.
Do the absolute smallest thing you know you need to do, like open your IDE, or write the class or function declaration.


Another thing that I think is important is demonstrating this behavior yourself. A lot of lectures and tutorials cover the happy path of developing code. Students see how easy it is when you do it, and then get home and don't know how to start and think that must mean they're terrible programmers. In fact every single programmer feels this way, so it's important that they know this. So I recommend doing a live demo of working through a problem, including stuff like using Google, looking stuff up in the reference, making mistakes, debugging, etc.