In the first few days of Hack Reactor it has become clear that software development is a consistently arduous, lonesome, and confusing vocation. So why do we torture ourselves? Because the tear-jerking moment when our code works is worth all the blood and sweat we put into writing it. If we wish to have any sliver of hope in earning that golden moment of success, we'll need to have the right approach. With that said, there are many tools, processes, and practices at our disposal in dealing with the seemingly bottomless abyss that we are so often thrown into - debugging being one of them.
The Debugger's Question
After hitting refresh a thousand times, staring blankly at our codebase, and finding a corner to shed some tears in, we'll probably need to start taking a logical approach to fixing the error that keeps breaking our code. One of the first steps is to open the developer console, see where (script and line) that error is taking place, and pose the Debugger's question: ""I was expecting X, but I'm getting Y, what justifies my expectation?"" The inquiry is simple, but the approach and foundation that come with posing the question are invaluable. The question creates a starting point; once we know where the error is and what should be taking place, we can begin to work backwards - Chrome offers some powerful tools to help with that.
Chrome Developer Tools
Chrome's developer tools utility makes working backwards a hell-of-a lot easier. The source tab enables us to look at the codebase directly in the browser. Once we have locked onto our error in the code and posed the debugger's question we can use a breakpoint to enable the program to stop on the line where the error is taking place the next time we refresh the page. Creating a breakpoint is as simple as clicking on the line number next to the code in the source panel. The next step is to refresh the page and begin to step back using the call stack. The call stack displays a clean list of the last 13 executions made by the program leading up to the breakpoint. As we step back into each execution, we have to remember to tell ourselves what we expected to be there, note that we're getting something else, and ask what justifies our expectation. Doing so will lead us to the point where the error stemmed from and why it has happened.
Unfortunately, we sometimes come across a situation where we know exactly what line the error is happening on but are still clueless as to where or when the error is occurring. These types of errors are often associated with being lost in the confines of an iterator. Luckily, Chrome Dev tools can come to the rescue once more. When dealing with a bug within an iterator, we ask ourselves: ""which iteration?"" In order to figure this out, we place a breakpoint inside the start of the iterator where the error is taking place, refresh the page, and then make use of the continue tool. Continue lets us pause every time the breakpoint is reached. With that in mind, placing a breakpoint within an iterator will create a pause on each iteration.
If we need to get even more specific, we can use the step over function tool that lets us move forward one by one through each execution. Additionally, watch expressions allows us to add expressions or variables and display the values that they reference. This tool can be particularly useful in keeping track of the values of variables and expressions as we move through each execution.
WARNING***: The knowledge that you have now gained from reading about the above tools and approaches may not stop you from bashing your head into your keyboard after hours of frustration. However, that probably doesn't matter to you since it's likely the very same reason as to why you keep coming back and torturing yourself again. You're a software engineer, a problem solver, an innovator, an explorer, and every rough patch that you encounter just drives you harder because the satisfaction of the solution will be that much stronger.