When should I stop struggling and look up a programming solution?

A useful middle ground is to ask for a hint instead of the solution. You can also write a detailed explanation of what the code should do, what it currently does, and everything you’ve tried. Explaining it to an imaginary listener—the classic rubber-duck technique—often produces an “aha” moment. If you still need help, ask a question that guides you toward the answer rather than giving away the finished implementation.

Don’t use a fixed timer as your only rule. First change your approach: take a break, write the problem down, solve it on paper, make a small flowchart, or describe the code out loud as if explaining it to someone else. That often reveals the missing assumption or step. Experienced programmers can spend days or weeks on genuinely difficult problems, so struggling for a while is normal—but the struggle should involve trying new approaches, not repeating the same attempt.

Before looking for a complete solution, figure out what kind of problem you have. If it’s an error, read the message carefully, isolate a minimal example, and check the official documentation or relevant examples. If it’s a logic problem, break it into smaller tasks, write pseudocode, and use a debugger or print statements to compare what you expect with what the program actually does. Search for the specific concept you’re missing rather than searching for the exact answer to the whole exercise.

The right time depends on your goal. For a small exercise, spending 30–60 focused minutes may be enough before researching a missing concept. For a larger project, several days may be reasonable. Once you read a solution, don’t just copy it: close it, explain the approach in your own words, implement it yourself, and then try a similar problem without help. That turns looking something up into part of the learning process instead of replacing it.