The Problem-Solving Treadmill (The Road to Nowhere)

By: Amy M Haddad

Most people want to get better at problem-solving, but aren’t sure how to go about it. So they default to what I call the “problem-solving treadmill.”

The problem-solving treadmill is all about quantity: solve as many problems as quickly as possible. Solve one problem, move along to the next. Solve another problem, move along to the next.

I was on the problem-solving treadmill myself when I began to program, and eventually noticed something interesting. I was sinking a ton of time and effort into the problem-solving process, but I wasn’t seeing the results. I wasn’t making much progress. In fact, I was going nowhere.

Eventually I realized the problems with this approach. Plus, if you’re looking to get better at problem-solving, there’s a far more efficient and effective alternative to consider.

Problem #1 with the Treadmill Approach

First, it can be detrimental to learning and improving, as I found out first-hand. I’d work on a related problem or attempt to re-solve a previously solved problem and find myself getting really stuck. I’d have no idea what to do. I didn’t learn what I needed to learn the first time around. Mistakes were made, concepts were confused, and progress was stalled.

Problem #2 with the Treadmill Approach

A second issue revolves around the quality of my solutions. If I did solve a problem, the quality of my solutions were suspect. Because I was in such a rush—I was focused entirely on quantity—that I sacrificed on quality: I never took the time to refine and understand my solution before moving along to the next problem.

This is a huge problem. Imagine a writer who’s assigned to write an essay. The writer writes a first draft and says they’re done.

No writer does this!

Any seasoned writer will tell you that the writing is in the editing. Whether you’re a writer of prose or code, you’ve got to revise, iterate, and find room for improvement. Only then do you really understand what you’ve set out to do, why, and how to make it better.

Quality vs Quantity

Repetition alone won’t separate us from the pack. The problem-solving treadmill isn’t going to get us to where we want to go.

And yet that mentality is pervasive. When most people set out to practice, they focus on mindless repetitions. Eventually you’ll get “good enough” and don’t have to think about it.[1]

However, mindless repetitions come at a cost: eventually you’ll hit a sufficient level and the skill becomes “automatic,” and we stop getting better.[1] Indeed, our “automated abilities gradually deteriorate in the absence of deliberate efforts to improve.”[1]

This is a call to action to get off of the problem-solving treadmill. Instead of focusing exclusively on quantity, we need to focus on quality. The quality of our problem-solving practice matters.

An alternative to the treadmill approach is to “look back” at your completed solution, as mathematician George Pólya puts it.[2] Looking-back means to “reconsider and re-examine the result and the path that led to it.” It’s the step to take after you’ve solved the problem.

The idea is to solve a problem. Then—and this is the important point—before rushing to the next problem, you look back at your solution: learn from it, improve it, and consolidate your knowledge, as Pólya suggests. For example, you solve a problem iteratively. Can you improve your solution by solving it recursively?

By looking-back at the problems you solve, you’ll find that your problem-solving skills and your programming knowledge will soar. Besides, the same patterns and data structures appear over and over again in programming problems. So it makes sense to nail the concepts when you’re working on them, than to let them fester and have to re-learn everything from scratch in a week or month down the road when you next encounter them. This is very time-consuming and frustrating.

The point is this: all programmers solve problems; it’s inherent in our craft. Just solving problems isn’t going to set ourselves apart. We’ve got to do things differently. We’ve got to work smarter. We’ve got to focus on the quality of our problem-solving practice, which looking-back will help you do.

I got off of the problem-solving treadmill a while ago, and began to “look back” at my completed solutions instead. And I’m glad I did. Only then did I begin to see progress being made and the results that I was after. In my experience, it’s the most effective and efficient way to get better at problem-solving.

References:

[1] Ericsson, Anders, and Robert Pool. Peak. New York, New York, Houghton Mifflin Harcourt Publishing Company, 2016.

[2] Pólya, George. How to Solve It. Princeton, NJ, Princeton University Press, 1985.