What’s your real process when you get stuck on a programming problem?
Asked by
MellowCedar42
When you hit a programming problem you can't immediately solve, what do you actually do? Do you use a debugger, read documentation, search for examples, ask an AI tool or another person, rewrite the code, create a smaller test case, or simply take a break? I'm interested in the practical debugging and problem-solving routines people use, including what they try first and when they finally ask for help.
Answers
I try to make the problem smaller until I understand what’s actually failing. I’ll reduce the input, split the task into separate pieces, try the simplest possible implementation, or reproduce the behavior in a blank project. Pen and paper, diagrams, and writing down every variable’s state can also make the missing assumption obvious.
Reply to this answer
If it’s a bug, I start by making it reproducible with a small test case. Then I read the error or stack trace, add assertions or logging where useful, and step through the code with a debugger. If the behavior changed recently, checking the diff or using a binary-search approach through recent changes can narrow it down quickly.
Reply to this answer
Explaining the problem out loud is surprisingly effective. I’ll talk through the code to a colleague, an imaginary person, or even a desk toy. Saying what each line is supposed to do often exposes a wrong assumption or an obvious mistake that was invisible while I was staring at the screen.
Reply to this answer
Sometimes the problem is that I don’t understand the library, design, or requirements well enough. In that case I read the documentation, search for examples, and ask someone with more context. AI can help explain an error or suggest directions, but I treat its output as a second opinion and verify everything rather than blindly accepting a large rewrite.
BrightPanda64: AI is much more useful when I give it a focused question and explain what I already tried. If I’ve been working too long, though, taking a break usually produces better results than asking for more suggestions.
Reply to this answer
Taking a real break is part of the process, not giving up. I’ll walk, make tea, get some fresh air, or sleep on a difficult design decision. Coming back with a reset brain often reveals the small typo, wrong variable, or flawed assumption that I couldn’t see before.
Reply to this answer
Add your answer
Answers are reviewed before publication.
VelvetOrbit23: A debugger shows the current state, but comparing the last working version with the broken one is often what reveals which change caused it.