You know them, those errors that make NO sense. Where it seems like a gremlin just jumped deep inside your chips and messed up something. Do you take a walk, write stuff, call an uncle?

  • 3
    Your description may be correct - Reboot and try again!
    – NoChance
    Commented Sep 3, 2011 at 3:32
  • 5
    post it on stackoverflow of course :)
    – William
    Commented Sep 3, 2011 at 8:44
  • 5
    Why did you decide on a threshold of 10 hours? That's way too long - if you don't have a good idea of what's causing unexpected behavior within an hour or two, you are in trouble.
    – Vector
    Commented Sep 5, 2011 at 20:37
  • 5
    "When the going gets tough, the tough go to sleep and let the subconscious work on it." -- anon Commented Sep 6, 2011 at 23:52
  • 2
    1. Get someone to help. Two people is a must. 2. Narrow it down using excessive amounts of debug statements. There was a file where every single line was preceded by a debug macro to pinpoint the one that segfaulted.
    – SF.
    Commented Sep 7, 2011 at 9:27

20 Answers 20


For those really horrible problems my strategy usually goes as follows.

  • Experiment and google. Keep trying to solve the problem. Most of the time this solves the problem in an hour or less.

  • So that hasn't worked. Take a break. Have a coffee, talk about something unrelated to a colleague. Push the problem out of your mind. When you look at the problem 5 or 10 minutes later you are looking at it from a slightly different perspective. Most of the time this works.

  • In this case it hasn't. So spend another 10 - 30 minutes looking at it. Then call in a colleague. But before you do, make some notes; you want to demonstrate the problem, reproduce it, then list of the things you have tried, and most importantly prove that you have tried them. So do a dry run first. Set some book marks in the code, close any superfluous open documents etc. This way you may either solve the problem yourself, or when you do demonstrate the problem you won't be wasting their time.

  • Ask your colleague to make you prove all your assumptions. is that setter actually being invoke? Is that method really returning what you claim it is? You think that object isn't null - show them it isn't null.

  • Most of the time, either demonstrating the problem will make you realise that you haven't tried all the possibilities or your colleague will see your mistake.

  • If that doesn't work its time to get serious. Document exactly what you are trying to do, what you have tried, and why it didn't work. Email this to all your colleagues. Post it on SO. At this point the document should be a perfect SO question.

  • While you wait for responses, google google google. Try every permutation of the question you have. Open up a bunch of tabs. You probably aren't going to get an answer by this point, but you're looking for ideas, possibilities, different ways of approaching the problem.

  • Do something else, if you've spent 5 hours on a problem its time to leave it for another day. Maybe you will get a useful response. Maybe when you attack the problem the next day it will be obvious.

  • If none of that works, its time to look for a different solution. Maybe you can use a different method, a different technology. Maybe you should consider abandoning the feature for now. Are you billing the client by the hour? Are you working for a company on an internal app? You need to escalate this to the owner and tell them "look, I've spent x hours on this and made no progress, is the cost benefit worth it?". You don't want to go to your boss and tell them you spent 16 hours on a problem only for them to turn around and say, it nots that important, skip it for this release. you need to find that out earlier.

  • And if that doesn't work? Well your only options are to keep hammering away at the problem or seek out industry expertise. Ask technology experts on twitter. Email your technology provider.


Quit. No, not your job! Just get up and go home. You're done for the day or the weekend. 19 times out of 20 when you come back to the problem next, the solution will present itself within an hour.

  • 17
    You could also try rubber ducking it. en.wikipedia.org/wiki/Rubber_duck_debugging
    – Dave Nay
    Commented Sep 3, 2011 at 2:11
  • 2
    19 out of 20, yes. My worst one never did get solved, only worked around. No test environment ever showed it, only the full production environment in operation--we couldn't even reproduce it after hours. Commented Sep 3, 2011 at 2:14
  • 3
    Getting away from something thats irritating you can be really hard - but I've found over the years that its always the best thing to do. The subconscious mind can work on the problem while you eat, sleep, good off, watch TV... and next day (or the day after) things go better. One word of warning though: gather information before you walk away... Walking away is not the same as ignoring it and pretending its not there. You still need hard work! Commented Sep 3, 2011 at 3:10
  • 1
    I do not know about an hour. I generally solve most of these types of problems in the shower when I get up in the morning. The second most frequent will be when i am nearly asleep at night and have finally allowed myself to stop thinking about it. Commented Sep 6, 2011 at 18:25
  • 3
    There was a fascinating NOVA Science NOW hosted by Neil deGrasse Tyson which talked about the science of sleep. In it was discussed the phenomenon of banging your head on a problem for hours, going to sleep, and waking up and solving it right away. When we sleep, our brain turns the events of our day over and over and over, analyzing it from many different angles. What it leaves behind are new neural pathways that can actually help us see the problem in a whole new way subconsciously, and then actually solve the problem. Pretty awesome. Commented Sep 7, 2011 at 0:05

Before ten hours go by, I would get some help.

  1. Describe the problem to someone else, anyone else, even your rubber duck.
  2. Ask someone else to take a look at the code, or step through it with them.
  3. Isolate it. Delete a bunch of stuff, then bring it back bit by bit until the problem reappears.
  4. Get some sleep!
  • 12
    +1 for deleting everything until the problem disappears.
    – Jonah
    Commented Sep 3, 2011 at 3:05
  • 4
    You should do one of those things before 1 hour goes by. The more you stare the less likely you are to achieve your epiphany. I normally solve a problem just by talking it through with someone.
    – Ben
    Commented Sep 3, 2011 at 21:43
  • Spot on. Often I figure out the problem, (or get close to it) by first describing the problem. Frequently this occurs while writing a description of the problem for a StackOverflow question. Which also requires a reduction (isolation) and then failing that, a wait period where you step away from the problem and let the SO answers come rolling in.
    – sholsinger
    Commented Sep 7, 2011 at 14:31

One word, timebox, set a limited amount of time to work on something, and if it isn't solved, move on to something else and come back to it the next day with a fresh perspective.

That and another set of eyes, is always worth more than any time you can waste staring at something.

I would never spend more than 45 mins to an hour trying to solve something in one sitting, it violates the law of diminishing returns.

  • Thank You So Much - I read the timebox article on wikipedia, very useful. Commented Sep 3, 2011 at 3:21

Explain the problem to someone else.

By explaining the problem to someone else, you have to clarify it: this often lets you see the solution.

(One of the UK professional computer magazines once proposed selling life size cardboard cut-outs of a senior programmer specifically for this purpose.)

I find sleeping on a problem (sometimes for a couple of days) can also help.

  • 1
    The "someone else" need not be human. Sometimes I explain things to the cat, and aha! I find the problem.
    – DarenW
    Commented Sep 4, 2011 at 4:49
  • I really should buy a cat too. I'd train it to scratch my head on demand. Commented Sep 6, 2011 at 17:18
  • Someone really ought to make a life size cardboard cut-out of Jon Skeet.
    – Don Roby
    Commented Sep 6, 2011 at 22:10

I have a three step plan:

  1. Get a coffee or other tasty beverage.
  2. Work on something else for the rest of the day.
  3. "Phone a friend" and doodle on the whiteboard.

Each stage is an escalation if the previous step failed. There's almost always something else productive I can work on at stage 2.

  • Nice advice! So "Phone a friend" is quoted because it should be limited to 60 seconds, like on Millionaire, yeah? I like the whiteboard idea too. Commented Sep 6, 2011 at 17:09
  • 1
    I find the whiteboard really helps think it through methodically. Quotes were because often the friend is in the same office so actually calling would be odd. But it sort of felt like a lifeline from the tv show.
    – Flexo
    Commented Sep 6, 2011 at 19:38

Sleep over it

Otherwise, call someone nearby and ask him to take a quick look over the code.

Often errors which would take you a long time to find (since its your code) are found very easily by others


You could see if getting up, pacing around, and thinking about the problem helps you find a solution. Whether or not you're actually standing or pacing, try getting away from the computer while you're thinking.


I generally do one of the three:

  1. Take a walk/bike ride...some that gets you away from the computer.
  2. Play with my dog or cat
  3. If you have a hobby, work on that for a while.

Any of the three do a good job of distracting oneself from the situation at hand. I find the distractions let my subconscious brain chew on something for a while. After an hour or so of this, bam, there's the solution :-).


Build a test Harness to target that exact Defect and Isolate it

Just keep eliminating good code.. while replicating the defect. Until you target the exact piece of code casing the error. Then trace the code.

Recommended reading : The Pragmatic Programmer Specifically Chapter 10 : Tracer bullets

  • all this is good and well but it takes for granted that the bug has been and can be reproduced. What if the 19 hours spent thus far were to just that... attempting to find a means to reproduce the problem in a deterministic and systematic manner... what then ? To me THAT is the essence of the question here !
    – Newtopian
    Commented Sep 7, 2011 at 4:58
  • The Pragmatic Programmer is excellent Commented Sep 7, 2011 at 19:02

All of these suggestions are great. However, I use a technique quite often that I didn't see mentioned. Make lists to organize your thoughts about the problem. If I have a particularly sticky problem I usually write out multiple lists such as: Facts, Assumptions, Questions, Symptoms, etc. I find that oftentimes in the process of organizing things in this way I discover assumptions I didn't realize I had (that often turn out to be wrong), questions I didn't realize need to be asked, other permutations I can check, etc.



The short answer:

Q: How do you tackle really bizarre errors that keep you puzzled for more than 10 hours?

A: Make sure they never happen: understand your design, know your code, learn how to use your debugger.


"Where it seems like a gremlin just jumped deep inside your chips and messed up something"

This should never happen. If it's your code, you should have a very good idea of what is causing the error before you attempt to fix it.

Futhermore, when you write your code you should already know where and why it's likely to fail.

Having said that - asking a peer, posting on SO, retracing and rolling back your steps and taking a break - all the suggestions mentioned above will help.

The other thing, is you must know your tools - your debugging toolkit. Logging messages at suspect points in your code, examining your call stack carefully, using conditional breakpoints and watches, etc etc. Debugging skills are not extras - they are part of programming.

  • Being able to retrace one's steps is vital. Thank you! Commented Sep 6, 2011 at 17:21
  • >Being able to retrace one's steps is vital. SourceControl software is the key to being able to rollback/retrace. Be ANAL about it and if you can, set your settings to force you to leave comments upon checkin.
    – Vector
    Commented Sep 6, 2011 at 18:55
  • 3
    Unfortunately, no matter how well you know you code, sometimes the problem is an interaction with someone else's (closed source) code.
    – Nate C-K
    Commented Sep 6, 2011 at 19:32
  • 2
    +1 @Nate CK- very true. The worst types of bugs happen when you get some sort of gibberish back from a web service you were relying on. I had an Saas vendor a while back who subtly changed some functionality without warning in their web service. I had to explain to the developer how to fix his own bug over the phone as he described to me what his code looked like.
    – user3792
    Commented Sep 6, 2011 at 20:10
  • 1
    To determine what? That there's a problem in 3rd party code? That part is relatively easy. The hard part is figuring out what conditions trigger it, and how to work around it, when you don't have the source, the vendor is not responsive, and perhaps it doesn't happen on your test system. If you think knowing your code is going to solve all that for you, I suggest maybe you've never had to deal with it.
    – Nate C-K
    Commented Sep 7, 2011 at 15:29

I had a similar problem, an apparent memory corruption in Objective-C, which I struggled with for many hours. But then me and my colleagues just took a walk for lunch, and I explained the problem (and one particular bit having to do with deserialization of an object in its init method), and basically explained the whole problem to myself.

(techy details: basically, I initialized and returned an object onto something else than self, so there were two allocs, but just one object returned. Memory shifted and went crazy, crashes, and the debugger didn't really know what to do with it either).

  • 1
    "I initialized and returned an object onto something else than self" - bugs like that are TOUGH! You can look it over 100 times and not catch it. But couldn't you see two allocations by tracing through in the debugger?
    – Vector
    Commented Sep 6, 2011 at 2:31

enter image description here

Take a bath.

Any Rodney McKay fans?

Seriously, though, if there's one commonality among all these answers, it's to take a break and do something else.

I like to think of it as relegating the problem to your subconscious. Even if we are otherwise unaware, our minds (seem to) continue to work on the problem, even when we're doing something else, such as taking a bath.

  • Great idea....now I just need to get the boss to put a half dozen soaker tubs in the office.
    – Dave Nay
    Commented Sep 5, 2011 at 18:53
  • If only the legion of cubicle workers each had a room like that. Commented Sep 6, 2011 at 17:02

Step through it step by step, down into assembly. Who calls what, break-point on memory access. That usually catches the bug real fast.

If not, take a walk.


A combination of all of these :

  • Get away from it for a while so it can sit on your back burner. Sleep, rest, eat, take a walk, whatever.

  • Examine the problem more, what else does it do wrong, what other symptoms can you find?

  • Research the problem, see what you can find. Remember to try different keywords

  • Try something different. A work around. A different debugging technique. A validator. A different computer.

  • Talk to someone. Even if they are not able to help, or not even a programmer, sometimes talking will trigger the idea lightbulb

  • Restart! If appropriate, try restarting your computer, the server, etc. If nothing else, you can use the time to think.

  • Ask StackOverflow! We are here to help


I really didn't like the most up-voted answer, because even though that sometime works, some times you just need to figure it out that same day, so what I'd recommend, in this order, is:

  1. Confirm that it's not only happening to you. This can save you a lot of time. Maybe you uninstalled a required component, or made a change in your environment, and an exception is being swallowed somewhere in your code. If it's happening only to you, I would use an environment comparison tool. I recently read about a software called Envy, which allows you to do just that, although it's not freeware, it costs 10 USD.

  2. Happening to everybody? Fine, now do a View History on the code and verify for recent changes that might have caused the error, either directly or indirectly.

  3. There aren't any recent changes? If it's a very specific error (an exception), 'stackoverflow it'. Now that doesn't sound better than 'google it' but I feel good to say I first search stackoverflow for programming research than google. If it's a really known issue, it's very likely that you'll find a solution here. If not, then post a question on the related stackexchange site. You might get a very quick answer, or even if you don't, your question will be out there while you do more research. That's a benefit.

  4. If you didn't find an answer online or it isn't a general error, then walk through the code step by step, checking if the obtained results of each step make sense for the result you expect. Go start to finish on each method, and bottom to top on a tiered solution. (i.e. if you're troubleshooting performance, start with the code that retrieves the records. doesn't make sense to start in the UI if you can determine quickly if the first step is the problem).

  5. If after going through the code a couple of times you still haven't found what's wrong, call-in someone to talk about it. As someone already mentioned, talking about it out loud can light the bulb. Plus pair-programming is really useful.

  6. At this point, if it's feasible, walk away either for some time or for the day. I read a very true tweet yesterday that said "I went to bed thinking 'how the fck' and woke up thinking 'but of course'". So true.

  7. If you still don't have an answer, I'd dare say you could try refactoring into smaller tasks/methods/functions. Henry Ford said something like 'There isn't a task so complex that cannot be accomplished by breaking it into smaller tasks'. At this point, if the solution is too complex and you haven't figured out either by yourself or with the help of someone else, refactor the code into smaller tasks. Even if you don't end up commiting it, it can help you find the reason.

  8. Add instrumentation to your code.

  9. Tweet about it??


You need to step back. My motto is 'if the problem is too hard then you are solving the wrong problem'. What are your assumptions? don't trust anything.

The corollary to that is 'the weirder the problem, the weirder the solution'. The computer's strength is its logic so you can't win on logic. You have a brain and have to out-think it.

In modern times there are so many other things interacting on a system - firewalls, AV, Antispyware, automatic updates happening every night - you have to deal with moving targets.

  • So true that 'the weirder the problem, the weirder the solution' Commented Sep 7, 2011 at 18:45

Google it. Stackoverflow it. Post it on forums. Basically if you can't solve it alone, get people to help.

  1. Write down the problem.
  2. Think hard.
  3. Implement the solution.
  • Concise, very good! Commented Sep 7, 2011 at 18:44
  • 1
    Actually, no. Thinking too hard along the same tracks is just about the worst possible thing you can do. 'Challenge, enumerate, revisit and test each of your assumptions, in a systematic way' is the solution here; people are discussing different tactics of achieving that.
    – smci
    Commented Jan 21, 2012 at 22:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.