One of my strongest skills is debugging and not just debugging with debugging of hard problems. Let’s define a hard problem. A hard problem is one that you spend, say, 20 to 30 minutes on, and you haven’t solved it yet. And as you know, if you do that, it can easily turn into hours. So what I do that makes me very good at this is after that 20 minutes of spent debugging, I stop what I’m doing. And don’t use the normal techniques anymore. What I do is take a step back and say, the behavior that I’m seeing is going to be a rational, logical reason that’s causing this behavior. The bug will be caused by a rational, logical reason it always is. Then I say what logical, rational thing would cause the behavior I am seeing? And if you look for that, you will often find the bug.
Secret to debugging hard problems
About the Author
Chad Jones
Chad is the Founder and CEO at Push and was a former Apple Engineer before returning to Saskatchewan to help revolutionize the mobile development world. Chad is passionate about creating efficient, well-designed software.