Speaking of tracing every line of code, a lesson that I have had to learn and relearn a couple of times over the years is that sometimes when you are really stuck, the best thing you can do is set a breakpoint, a point in the code that tells the debugger to stop execution, set up to watch a specific variable, and start stepping in and out of methods.

It was not that long ago that I had spent 6 hours with no luck trying to figure out an issue. I set up the Visual Studio Debugger and watched the call stack for a single pass through and noted an odd occurrence--it was fixed in 3 minutes. Seriously, 3 minutes after hours of beating my head against a wall--I can be stubborn at times.
Let's have a look at the currentBallSpeed variable:

Here's another example. I was having issues with the speed of the game ball and wanted to see what is happening with the currentBallSpeed variable. I set a breakpoint on the line after the currentBallSpeed was updated, then I set a watch for that variable. I them ran the program on my HoloLens and connected the debugger. At this point, I just let it hit the breakpoint and hit continue again. This process was pushing it further one frame at a time, so I could see the numerical value for the speed the ball was moving. I noted that the value was correct in terms of the direction it was going, but I also noted that the number was jumping nearly 100 per frame; there was not enough resolution. This explained a few issues I had noted. Now those issues are addressed.

It doesn't matter what debugger you stick to as your go-to option; you must familiarize yourself with this debugger and the process. It can be a life saver. That said, at times it can be slight touchy about working with HoloLens. Sometimes it is amazing, other times a trial.