| A lot of us believe that we spend a much smaller portion of our time looking at or debugging existing code than we really do. If you don't believe it's a time suck then you have very little incentive to keep pushing to get better at it. So the majority of us quickly reach a point where we are satisfied that we 'know how to debug' but leave a lot of room for improvement on the table. The best description I've heard for master-level debugging is that it's a process of narrowing down the problem space as cheaply as possible. Your brain is telling you that based on everything you 'know' about the code, the right answer should come out. If the wrong answer is coming out, something you 'know' is wrong. After the most obvious failure mode doesn't reveal the problem, your next check may not be the second most obvious failure. Instead you're multiplying the cost of verifying an assumption times the likelihood it's correct times the 'area' of the problem space it eliminates. Checking things like "is it plugged in?" sounds stupid but brings down the worst-case resolution time by hours. Long story short, let's say I'm sitting in an interactive debugger looking at a stack frame, expecting that a particular variable has the wrong value, but it's fine. The cheapest thing for me to do next is to look at all of the neighbors of the suspicious value, and those in the caller and on the return. With println, pretty much every subsequent check costs the same amount as the first one. And if there's no short path from starting the app to running the scenario, that cost could be pretty high. If you believe that you have a high success rate on your first couple of guesses, then println works great for you. But what if you're wrong? Have you ever tracked how many attempts it usually takes you? Or are you too wrapped up in the execution to step back and think about how you could do better next time? Also, I want to be clear that I'm not telling anybody how to debug, as long as you aren't making that choice for your whole team. Don't choose tools or code conventions that break interactive debugging because "println was fine for grandpa so it's good enough for me!" That's a big ol' case of Chesterton's Fence. |
Having experienced the higher plane of fully integrated IDE / run / debugging with arbitrary expression evaluation, conditional breakpoints, etc, I can't even imagine how anyone could work with "print debugging".