I use my eyes. If I can narrow it down to what line, or even file, is throwing an error I just take a few minutes, read all the code and all the code of branch

I use my eyes. If I can narrow it down to what line, or even file, is throwing an error I just take a few minutes, read all the code and all the code of branching methods, and then can narrow it down to a single line. From there it is actually developing a fix. As you mess around with more and more languages, you will notice that most compilers lend something far from a helping hand. This only works, and I will stress this, for programs under 1 million lines. Past that mark, you need to do some extra steps. When I debug one million line projects, I narrow it down to a file. I pull out the code from the file, and I mock all of the methods that file calls (This gets REALLY hard with networked code. Trust me). From this small subset, I slowly break the functionality of the external method until I resemble the error being made in the main project. From that I now know the method(s) that are actually causing the problem. But, there is one thing that this makes an assumption about: your compiler is working. Put blatantly, they're crap. Usually they won't show you the correct file causing the error or they will not generate a helpful error. Runtime errors are even worse. The best thing to do is avoid making the tricky errors. Make unit tests, using fuzzing tests, and well made documentation. Documentation alone, that details all of the possible output and input states of the function will save you days on some bugs. In Java, the @Nullable tag is a godsend. Use these features, they WILL help. If you do tests, fuzzing, and documentation. Using your brain and some things to make your brain's job easier will make you faster at debugging then any debugger like your buds GDB/DDD setup.