To get better at programming or math, it’s not enough to read about a topic. You have to solve problems. And solving problems is a lot more beneficial if you have access to solutions, especially ones with detailed explanations. But as useful as solutions are, they also present another problem: when is the best time to look at them?

Solving a problem yourself improves your understanding of a concept more than reading someone else’s solution. If that wasn’t true, then it would be possible to learn a technical subject just by reading about it. That would be easier, but it doesn’t work. So you need to struggle with problems.

However, you can’t avoid looking at the solution forever. Problems in textbooks or online judges are intended to be solved in hours or days. They aren’t unsolved research problems that take months or years to solve. (Or if they are, they’re clearly marked as such — e.g., some of the problems in Knuth’s books).

So part of your job as a problem-solver is to settle on the best time to look at each solution.

## Types of Problems

The decision to look at a solution is a trade-off. You have to evaluate the costs and benefits of continuing to work on the problem on your own and compare them to the costs and benefits of reading the solution. The cost of sticking with the problem is time that you could be spending on other problems, or other activities. The benefit is the chance to exercise the problem-solving parts of your brain on this particular problem. The benefit of looking at the solution is immediately learning something about the problem, and getting to move on to something new. The cost is giving up the chance to solve the problem without help.

You’ll need to weigh the costs and benefits differently in different settings. Here are some examples:

In a timed exam, you have to decide quickly whether it’s worth continuing to work on a problem that you’re having trouble with. The best strategy is often to move on to other problems that you’re more likely to solve.

On a professional team, there’s a high cost to waiting to look at a solution. If you suspect that someone knows the solution to your problem, your colleagues will expect you to act on that assumption. You don’t have time to rediscover everything on your own when Stack Overflow already has answers to every simple programming question. Similarly, if someone on your team is an expert in an area that you’re having trouble with, you won’t be faulted for interrupting them a reasonable number of times per day. Incidentally, one of the reasons for professional developers to work on side projects and programming puzzles is to get the learning benefits of reinventing the wheel without delaying anyone else’s work in the process.

If you’re solving problems for a class, then the type of class will affect your strategy. A traditional class is a bit like an exam, in that you have a fixed period of time to solve a specific set of problems. If you spend too much time on one problem, you might jeopardize your ability to finish the other problems, or other classes. If you’re taking a class with less of a fixed schedule, like some MOOCs, you might decide to spend more time on a particular problem that you find interesting.

No one has unlimited time to solve a problem, so it isn’t realistic to work on every problem until you find the solution. However, some people have a lot more problem-solving time than others. If you’re working on a difficult research problem, you might be able to spend years on it. (Andrew Wiles worked for seven years before presenting his proof of Fermat’s Last Theorem). Even in business, if you’re building new technology from scratch, you’ll be allowed to dedicate more time to it than if you’re customizing something that already exists.

## Principles

Here are some principles to use as you decide how long to work on a problem:

**Work as long as you’re making progress**

Rather than working on each problem for a fixed maximum period of time, keep working on them as long as you’re getting results. In other words, if you’re making progress on a problem, why stop working on it?

But this principle doesn’t completely answer the “how long” question. It just transforms the question into, “How long should I continue working on a problem if I’m not making progress.” As with the original question, the answer depends on the type of problem that you’re working on, as well as the other principles in this section.

**Work after you get stuck**

Except for very simple problems, it’s good practice to spend some time on a problem after you run out of ideas. You don’t want to train yourself to give up too easily. Pushing past the initial failure is also a way to practice thinking creatively about what approaches might work.

**Take breaks**

If you have time, it’s useful to let your brain work on a problem while you’re doing something else. This is another form of practice that you could miss if you insist on solving every problem in one sitting.

**Collect data**

There’s nothing wrong with looking for a quantitative answer to the “how long” question. To get that answer, collect data about your problem-solving activities. The most basic data to collect is how long you spend on each problem. You can then process this data to get some useful results. For example, I keep track of my time as I’m working on Project 462 problems. As a result, I know that I spend a median time of 2.5 hours per problem, but that I have spent as little as 13.5 minutes and as much as 37.75 hours on a problem.

Having hard data about your problem-solving history can help you decide how long to work on a problem, especially if you have information about the intended problem difficulty. uHunt indicates the “level” of each problem, a number which should correlate with the amount of time required to solve it.

## How to Use Solutions

When you decide that it’s finally time to peek at the solution, don’t just dive in. There are ways to optimize your learning results even once you have done everything you can on your own.

**Read the solution gradually**

Maybe all you need to solve a problem is a hint. A well-written solution will let you read a bit at a time and try out ideas as you read them. You might be able to solve the problem on your own after reading the first sentence of the solution. That makes the solution more valuable than if you read the whole thing at once, since you still get most of the benefit of solving the problem on your own.

**To understand the solution, you first have to understand the problem**

Good solutions are written with the assumption that readers have already thought about the problem. Even if you can’t solve a problem completely, thinking through it before you read the solution allows you to compare your own thought process with that of the solution author.

**Calibrate your time-to-look**

When you’re done reading a solution, evaluate what you got out of it. If solutions often just remind you of something you already knew, you may be looking at them too soon. On the other hand, if you often find information in solutions without which the problem would be impossible to solve, then you may be waiting too long to look at the solution. Or you may be working on problems that you’re not ready for. Problems are usually written to test specific techniques. Without exposing yourself to those techniques before you work on the problems, you’ll have to re-invent techniques that smart mathematicians and computer scientists took years to come up with.

(This “calibrate your time-to-look” idea is inspired by a Quora answer by Khalid Jamal Abdulnasser).

**Read the solution even if you solve the problem on your own**

As I explained in When to Peek at the Solution, comparing your solution to an expert’s solution is one of the main ways to gain expertise. So even if an online judge accepted your answer on the first try, you haven’t necessarily gotten everything you can out of a problem.

## Sources

- How much time should be spent working on a single problem on sites like Codeforces, CodeChef, etc. before reading the solution in its editorial?
- How long should I stay working on a math problem I am stuck on before asking?

(Image credit: Erik Fitzpatrick)