Productive Struggle
Two Types of Struggle
When working through a challenge - in programming or otherwise. We often find ourselves struggling to understand the problem, or developing a solution. This struggle isn’t bad, its just part of the process! But, there are different ways of struggling through a problem - some more productive than others. We can generally group these behaviors under either Productive Struggle or Unproductive Struggle. Productive struggle moves you closer to your goal, while unproductive struggle is stagnant, or can even move you further from your goal.
Identifying Productive Struggle
With your breakout group, the tallest person will share their screen and take notes as you brainstorm. Create a chart listing out behaviors that indicate when you are in productive struggle, and when you are in unproductive struggle. Take 8 minutes to just list the behaviors for each form of struggle - we’ll work on strategies for avoiding unproductive struggle next.
Once you have your list, take another 8 minutes to brainstorm ways to avoid unproductive struggle, and ways to move from unproductive to productive struggle. Create a separate chart listing out these strategies.
Strategies for Breaking out of Unproductive Struggle
Clarify the Problem
Revisit the project spec, interaction pattern, or any supporting documents to clarify the problem you are working on. Ask questions if necessary, and restate the problem to yourself and others to make sure you are working on the correct task.
Think Out Loud
Sometimes referred to as Rubber Ducking. It can often help to talk through what you are trying to do out loud - either to yourself or to another person. Just saying something out loud can help you identify where you have made a wrong move.
Take Notes
Write done what you know and what you have tried. Writing down what you know (what variables you have access to, what datatypes you are working with, what the return value of a method should be) helps focus you on the problem at hand, without getting caught up in other things. Keeping track of what you have tried and the result of those attempts can help you keep moving forward without re-trying things that you have already seen didn’t work. It will also help others follow your logic if you need to ask for help!
Try a Different Method
This might seem like common sense, but it is also a common trap that we can get into - we want so much to use a specific method, that we can tie ourselves to something that isn’t going to work. For example - if you are using .map and it isn’t working, try .each. Focus on getting it working, rather than on using the right method.
Nuke It
CODE IS CHEAP. It’s a tough lesson to learn, but a good one– it costs nothing to delete and start over. All developers sometimes get stuck trying to force our code into a strategy, tool, or path that we’re mentally stuck on and determined to make work. And sometimes, that just isn’t the right direction. It’s okay (and sometimes, the best course of action) to delete what you’ve written, take a 5 minute pom, and start fresh when you get back as though it’s the first time you’ve seen the problem. (Disclaimer: we’re not talking about a whole project here– don’t delete your whole project the night before it’s due).
Ask for Help
Early! Don’t spend too much time struggling before asking for help– if you’ve spent more than 20 minutes on unproductive struggle, ask a fellow student, mentors, upper mod students and/or your instructors.
Remember
Unproductive struggle is independent of how long it takes you to find a working solution. It is, however, recognizing when you’ve stopped learning.
