

Use the Surrender Tactic: Frustration when debugging - kedyr2
http://kedyr.wordpress.com/2013/03/30/use-the-surrender-tactic-frustration-when-debugging/

======
davidroberts
When I was learning to code C, I would often spend all night trying to chase
down a bug, then finally go to bed in frustration at 5 am. After a few hours
of sleep, I'd look at the code again, and immediately see the problem. I would
feel so stupid for missing it before. Surrender works. Or maybe debugging all
night doesn't work...

~~~
greenyoda
A good night's sleep can get you a few dozen extra IQ points. Amazing how many
bugs get solved by ideas that magically pop into your head while you're
showering the next morning.

~~~
nessus42
I sometimes solve problems _while_ asleep. I.e., I wake up just knowing the
answer.

------
tantalor
I have a sense of when I'm getting closer to a bug. As long as I'm making
progress I won't stop until I found the bug. That's not wasted time. If you
need two hours to do this, then you spent that two hours working on the bug.

On the other hand if you spend a lot of time with no progress, then maybe you
should stop and come back to it later, depending on priority, etc.

------
Robadob
I just solved a bug in someone's CUDA agent based modelling library which
caused a runtime error when compiling for a more recent CUDA compute
architecture. The actual bug was due to the more recent architecture enforcing
pointer alignment, while the older implementations just ignored it. My fixing
of the bug, created other bugs (largely due to my lack of CUDA experience)and
I eventually solved it by coincidence when applying my fixes from a reset
across the whole code, rather than at a local level.

I may have made no progress towards the task in these 2 full days I spent
working solving this issue, however I have greatly improved my CUDA
programming knowledge and debugging technique, which I would have otherwise
never done, so when I inevitably reach another bug It should (hopefully) be
much quicker for me to solve.

~~~
seanmcdirmid
Ah, pointer alignment bugs...I remember this being a big thing when porting C
code from the X86 to the Alpha.

------
lalos
You can also avoid getting frustrated by using a more test driven development.
Incrementally write code, then test (could be just printf-ing), then chances
are that the bug is in the last chunk of code written.

~~~
sax
I am working on a project that aims to standardize the use of bisection to
narrow-down and arrive at root-cause of bugs. One approach is to run regex on
your output logs to determine what modules are running into issues. check out
<http://bisect.cc>

~~~
banachtarski
what are the differences between a vanilla `git bisect`

------
knkl
If you use a version control system, write a test case and bisect (as in git-
bisect(1)) to find the root cause.

------
tlarkworthy
5 days to fix a bug! Jesus, write better code, write tests, with good logging.
Break your code apart into testable modules. Test you hypothesis from he
ground up. If you can't localise the bug quickly there is something wrong with
your methodology. You need to use a debugger. Clearly you are trying to debug
a house built on sand. I find this is a common problem. People don't realise
80% of your time is spent debugging and checking your assumptions. If you are
writing reams of code before checking your assumptions than you pay quadruple
cost. The first thing I do when building a big data processing project is
think about how I am gonna debug it first. Invest tons of time at the
beginning getting readable output in a console. I have gone as far in some
projects to output trees and grids in ASCII art to visualise data structures
(in the console). I have never spent 5 days debugging a bug since university.
The days spend at the beginning of the project making the debug output as good
as possible pay for themselves a hundred times over.

~~~
greenyoda
Sometimes bugs are genuinely hard to debug and appear in hostile environments.
Many people who have been programming for a long time have seen bugs that take
much longer than five days to debug. For example:

\- The bug doesn't reproduce when run under the debugger (not so uncommon with
C code). Or the bug goes away when you change the timing of the code by
writing to a log file.

\- The bug could be in code that you didn't write and don't yet completely
understand; the people who wrote the code have all left the company.

\- The bug can be in a third-party library that you don't even have the source
code to. You can only infer what the library is doing by seeing how it reacts
to what you're passing it. Or you can try disassembling its code.

\- The bug can be due to bad machine code generated by a compiler.

\- The bug can be due to undocumented behavior in an operating system.

\- The bug could be in a really complex algorithm.

\- The bug might only reproduce at a customer's site with the customer's
confidential data.

\- The bug might be sporadic, perhaps depending on certain patterns of network
traffic.

\- The bug could be due to a fundamental misunderstanding of the original
project requirements that will only become apparent after days of
investigation.

