What to Do When You're Stuck on a Bug for Hours

TL;DR - Try genuinely for 20 minutes before asking for help. Not 5, not 90. Twenty. - Explain the problem out loud to yourself. The rubber duck technique works. - Narrow the problem systematically: binary search debugging, check recent git changes, read the stack trace carefully. - When you ask for help, come with your process, not just your problem. - If you have been stuck for more than a few hours, communicate it proactively. - Document the bug and the fix when you solve it. Future you will thank you.

Every engineer gets stuck. Senior engineers get stuck. Engineers with twenty years of experience get stuck. Being stuck is not evidence of inadequacy. It is a routine part of working in complex software systems where no single person understands everything.

What matters is not whether you get stuck. It is how you handle it.

Junior engineers who struggle tend to do one of two things: they either spiral in silence for hours, convinced that asking for help will expose them as incompetent, or they ask for help after two minutes without having tried anything yet. Both habits hold you back.

The engineers who grow quickly learn a process. They spend real effort working the problem themselves. They use systematic techniques. They know when to escalate. And they build a practice of documenting what they learned so the next stuck moment is shorter.

The 20-Minute Rule

Why 20 minutes and not more or less

The 20-minute rule is simple: when you hit a bug or get stuck, work on it genuinely yourself for 20 minutes before asking anyone for help.

Not five minutes. Five minutes is not enough time to even fully understand the problem. You have not given yourself a real chance.

Not two hours. Two hours of spinning in silence is not heroic. It is a drain on your productivity and your team's. Managing your time well as a junior engineer covers how to communicate when you are behind, which connects directly to how you handle getting stuck.

Twenty minutes is enough time to read the error carefully, try at least one or two hypotheses, and develop a concrete description of what you are seeing versus what you expect. It is also short enough that if you are completely blocked, you have not wasted half your day.

The 20-minute rule is not about waiting a specific number of minutes before asking. It is about ensuring you have done real work on the problem before you bring it to someone else. What counts as real work: reading the error message fully, checking the relevant code, forming at least one hypothesis and testing it, searching for the error message online.

What not to do in those 20 minutes

Staring at the screen hoping something will click is not debugging. It feels like working because you are paying attention, but you are not generating new information.

Randomly changing things without understanding why is also not debugging. If you are modifying code and running it again without a hypothesis about what the change should do, you are guessing. Guessing can occasionally produce a solution, but it does not help you understand what was wrong. You will hit the same class of bug again.

In the 20 minutes, you are trying to answer: what exactly is happening, and where is the gap between that and what should be happening?

The Rubber Duck Technique

What it is and why it works

Rubber duck debugging is the practice of explaining your problem out loud, in detail, to something that cannot respond. A rubber duck on your desk. A blank document. A houseplant. The specific audience does not matter.

It works because the act of articulating a problem forces you to organize your thinking. Many engineers discover the answer in the middle of explaining the question. The moment you have to say, out loud, "and then I expected the function to return X, but it returned Y, which means..." you often catch the flaw in your own reasoning.

This is not a junior engineer technique or a beginner technique. It is a technique that experienced engineers use regularly because it is effective.

How to do it

Explain the problem from the beginning. Not just the immediate error. Start with what you were trying to do, what you did to do it, what happened, and what you expected to happen. Walk through the relevant code step by step. Note where your expectations and reality diverge.

You do not need a real listener. Just say it out loud. The act of speaking it is what matters.

If you do this for three minutes and have not found the answer, you now have something more valuable: a clear problem statement. When you ask someone for help, you can give them that statement rather than showing them a screen and saying "I am not sure what is wrong."

Systematic Narrowing

The binary search approach

Binary search debugging is the practice of eliminating half the possible locations of a bug with each test.

If your code has ten steps and produces a wrong result at the end, you do not need to examine every step equally. Add a log statement or a breakpoint in the middle. Is the state correct there? If yes, the bug is in the second half. If no, the bug is in the first half. Repeat until you have isolated where things go wrong.

This approach is more efficient than reading code from top to bottom looking for anything suspicious. It forces you to generate a hypothesis ("I think the state is correct after step 5") and test it, which is the core loop of good debugging.

Reading the stack trace

Many junior engineers look at a stack trace and see noise. With practice, you see information.

A stack trace is a record of where the error happened and how the code got there. Read it from the top, which shows the immediate error location. Then follow the chain downward to understand what called that code, and what called that, all the way back to your application code.

The goal is to find where in your code (as opposed to a library or framework) the unexpected behavior originated. Library code is usually not the problem. Your code is usually the problem. Find the last entry in the stack trace that lives in your application, and start there.

Read the error message itself carefully before doing anything else. Sounds obvious, but engineers often glance at the error and start guessing before they have actually read what it says. Error messages in modern frameworks are often specific and useful.

Checking recent git changes

One of the most reliable debugging shortcuts: when something worked before and does not work now, check what changed.

git diff shows you uncommitted changes. git log shows you recent commits. git show [commit-hash] shows you what changed in a specific commit.

If a test suite was passing yesterday and is failing today, the cause is almost always something that changed between yesterday and today. Find the change, and you have likely found the bug.

This approach is faster than re-reading all the code because it constrains the search space dramatically. You are not looking for a problem anywhere. You are looking for a problem in the delta.

Checking the obvious things first

This is embarrassing to admit, but a significant number of bugs come down to: wrong environment variable, outdated dependency, database not running locally, cache not cleared, old build still running.

Before you dive deep into a logic problem, run through the obvious mechanical possibilities. Is the server actually running the code you think it is? Did you save the file? Did you restart the process after your change? Is your local database schema up to date with the migrations?

These feel too simple. They are also the cause of real problems more often than any engineer would like to admit.

When and How to Ask for Help

The right time to ask

After the 20-minute rule is satisfied, after you have tried the rubber duck, after you have narrowed the problem as far as you can with your current knowledge, and you are still stuck: that is when you ask for help.

You are not asking because you gave up. You are asking because you have hit the edge of your current knowledge and continuing alone would cost more time than it is worth.

There is no shame in this. It is efficient and professional.

The engineers who never ask for help are not heroes. They are often slower, more frustrated, and more likely to ship code with bugs they could have caught if they had gotten a second pair of eyes.

How to ask well

The quality of the help you receive is largely determined by the quality of your question.

A poor ask: "Hey, I am stuck on this bug. Can you take a look?"

A good ask: "I am seeing a 422 error when I submit the form. The error message says invalid parameters but I have checked that the params hash includes everything the controller expects. I have confirmed the front end is sending the right payload in the network tab, and I have logged the params in the controller and they look correct. I am not sure where the mismatch is. Can you look at this with me for a few minutes?"

The second version tells your colleague what the problem is, what you have already tried, and what you are looking for. They can immediately contribute something new rather than starting from scratch. This respects their time. It also demonstrates that you have done real work, which builds your reputation.

Asking questions at work covers this in more detail, including how to gauge when to ask your manager versus a teammate versus Stack Overflow.

Working with a senior engineer on a debugging session

When a senior engineer helps you debug, pay attention to their process. Watch how they read the error. Notice what they check first. Observe how they form hypotheses and test them. You are not just getting this bug fixed. You are watching a debugging process that you can replicate.

After the session, ask one question: "Is there anything you would have tried earlier in this process that would have gotten here faster?" Most senior engineers will give you a useful answer, and it adds to your toolkit.

Working with senior engineers covers how to extract maximum learning from these collaborations.

If You Have Been Stuck for Hours

When to communicate proactively

If you have been stuck on something for more than two to three hours and your progress is genuinely blocked, that is worth surfacing to your team before the sprint ends.

"I have been working on this bug since this morning and I have not been able to isolate it yet. I wanted to flag that in case it affects the sprint timeline." That is a professional update. It gives your team information they need.

The impulse to stay quiet and hope you solve it is understandable. But if you do not solve it and the sprint ends with the ticket incomplete, that will be a larger conversation than the proactive update would have been.

The Thing Most Engineers Skip: Documentation

Why you should document the bug and the fix

When you solve a hard bug, the relief is immediate and the urge to move on is strong. Most engineers do. They close the issue, commit the fix, and start the next ticket.

This is a mistake.

The bug you just spent hours on is exactly the kind of bug you might encounter again in six months. Or a teammate might encounter it next week. If you take ten minutes now to write down what the bug was, what caused it, and what fixed it, you are doing future work that will pay back many times.

Where to put it depends on your team. Some teams have internal wikis. Some use Notion. Some have a #debugging-notes Slack channel. The format does not matter. What matters is that it exists somewhere searchable.

Engineers who document their debugging findings are noticeably more helpful to their teams over time because they become a reference resource rather than just a producer of tickets. This kind of contribution is visible and valued even if it is not strictly required.

What to write

The bug: what was the symptom. What error message appeared, what behavior was unexpected.

The cause: what was actually wrong. Be specific. Not "there was a type mismatch" but "the controller was receiving the user ID as a string because the form was sending it from a hidden field, but the database query expected an integer."

The fix: what change resolved it and why it worked.

Any additional notes: were there related issues? Anything to watch out for in similar code elsewhere?

Four to six sentences. It takes ten minutes and it is worth it.

For the moment when you are ready to ask for help but unsure how to frame it, asking questions at work covers how to do it without undermining your credibility.

For a broader look at how to build a strong reputation in your first engineering job, the first 90 days as a software engineer is the full picture.

If you want structured support building engineering habits that accelerate your growth, here's how the Globally Scoped program works.